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PREFACE 


IDEFq  is  based  upon  SofTech's  Structured  Analysis  and  Design 
Technique  (SADT).  SADT  concepts  stem  from  a long  history  of  problem- 
solving theoretical  efforts  by  D.  T.  Ross,  as  influenced  by  the  "Human- 
directed  Activity  Cell  Model"  approach  of  Dr,  S,  Hori,  then  of  IITRI.  The 
SADT  method  was  first  formalised  in  a joint  course-preparation  program 
partially  funded  by  ITT,  Later  a subset  of  this  material  was  revised  and 
published  as  IDEFq  under  the  ICAM  Program. 

Principal  contributors  to  the  development  of  IDEFq  are) 


D.  T.  Ross 

MIT  and 

SofTech,  Inc, 

Developer  of  original  concepts 

S.  Hori 

IITRI 

Developer  of  Cell  Modeling 
Concepts 

C,  G.  Feldmann 

MIT  and 

SoiTech,  Inc. 

Primary  author  of  first  SADT 
Reference  Manual  and  manager 
of  first  IDEFq  applications 
projects. 

D.  E.  Thornhill 

SofTech,  Inc. 

Primary  author  of  first 
formal  SADT  course  material 
and  application  to  government 
and  commercial  projects. 

R.  R.  Bravoco 

SofTech,  Inc, 

Application  of  SADT  and 

IDEF  to  Manufacturing 

M.  F.  Connor 
and  D.  A.  Marca 

SofTech,  Inc. 

Developer  of  revised 
commercial  SADT  materials 
and  applications  to 
commercial  projects. 

Judy  Kornfeld 

SofTech,  Inc. 

Developed  criteria  for  judg- 
ing quality  of  IDEFq  modele. 
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INTRODUCTION 
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INTRODUCTION 


The  U.  S.  Air  Force  Program  for  Integrated  Computer  Aided 
Manufacturing  (1CAM)  is  directed  toward  increasing  manufacturing 
productivity  through  the  systematic  application  of  computer  technology, 

The  ICAM  Program  approach  is  to  develop  structured  methods  for  applying 
computer  technology  to  manufacturing  and  to  use  those  methods  to  better 
understand  how  beat  to  improve  manufacturing  productivity. 

The  ICAM  Program  identified  a need  to  better  communicate  and 
analyze  manufacturing  for  the  people  involved  in  improving  productivity. 
To  satisfy  that  need,  the  ICAM  Program  developed  the  IDEF  (ICAM 
Definition)  method  to  address  particular  characteristics  of  manufacturing. 
IDEF  is  comprised  of  three  modeling  methodologies  which  graphically 
characterize  manufacturing) 

IDEFq  ia  used  to  produce  a function  model  which  is  a structured 
representation  of  the  functions  of  a manufacturing  ayatem  or  environment, 
and  of  the  information  and  objects  which  interrelate  those  functions. 

IDEF^  is  used  to  produce  an  information  model  which  represents 
the  structure  of  information  needed  to  support  the  functions  of  a 
manufacturing  system  or  environment. 

IDEF^  is  used  to  produce  a dynamics  model  which  represents  the 
time  varying  behavior  of  functions,  information  end  resources  of  a 
manufacturing  system  of  environment. 

Each  of  the  three  models  individually  or  any  group  of  models  can 
form  an  "ARCHITECTURE"  when  the  environment  of  system  being  modeled 
is  comprised  of  component  systems,  organizations  and/or  technologies 
which  must  work  together  to  accomplish  the  overall  objective  (production) 
of  the  manufacturing  environment  or  system.  The  significance  of  the 
models  being  referred  to  as  "ARCHITECTURES"  is  that  they  are  blueprints 
or  frameworks  which  define  graphically  the  fundamental  relationships  - the 


functional  interfaces,  identification  of  common,  shared  and  discrete 
information,  and  dynamic  interaction  of  resources.  It  is  important  to 
recognize  that  the  IDEF  models  become  Architectures  when  used  to  better 
understand,  communicate  and  analyze  not  only  the  subject  environment  or 
system  (manufacturing)  but  how  its  constituent  components  (system, 
organizations  and  technologies)  fit  together. 

IDEF  la  a method,  Architecture  is  a means  and  improving  manu- 
facturing productivity  ia  the  end  which  the  ICAM  Program  ia  pursuing 
within  the  U.  5.  aerospace  industry, 

The  following  material  ia  a diacuasion  of  the  fundamental  concepts, 
techniques  and  procedures  regarding  the  use  of  IDEF^  to  produce  a 
function  model. 


SECTION  2 


IDEF  CONCEPTS 


CONTROL 


idefq  concepts 


2. 1 ^Background 

The  desire  of  the  U,  S.  Air  Force  to  reduce  costs  and  lead  times 
by  assisting  the  Aerospace  Industry  in  its  modernisation  efforts  has  been 
evidenced  in  the  many'*<Tech  Mod^CTechnology  Modernization)  programs 
now  underway.  A dimilar  goal,  but  using  an  industry-wide  target  rather 
than  individual  companies,  was  established  under  the  ICAM  Program.  In 
ICAM,  the  goal  was  to  develop  "generic  subsystems"  which  could  be  used 
by  a large  number  of  companies  to  provide  a significant  upgrade  to  the 
industry  as  a whole.  These  ^subsystems  ’ provide  support  for  common 
manufacturing  functions  such  as  management  of  information,  shop  floor 
scheduling,  and  materials  handling. 

This  ambitious  goal  needed  a common '"baseline"*’ communication 
vehicle  around  which  to  plan,  develop,  and  implement  the  subsystems  in 
the  individual  Aerospace  Companies.  This  baseline  was  called  the 
^"Architecture  of  Manufacturing*^  since  it  was  to  provide  an  industry-wide 
^"architecture"*  showing  how  industry  works  today  and  around  which 
generic  subsystems  could  be  planned,  developed,  and  implemented.  ^ 

To  develop  the  Architecture  of  Manufacturing,  a "language"  was 
needed  in  which  to  express  and  document  current  Aerospace  Industry 
operations.  At  the  outset  of  ICAM,  the  Air  Force  issued  a Request  for 
Proposal  to  build  the  architecture.  A "cell  modeling  technique"  was 
specified  as  the  expreeaive  language  (where  a "cell"  was  defined  as  a 
manufacturing  cell,  or  operational  unit).  To  be  successful,  the  language 
had  to  satisfy  the  following  criteria! 

• Since  the  architecture  is  to  depict  manufacturing, 

it  must  be  able  to  express  manufacturing  operations 
in  a natural  and  straightforward  way. 

• Since  the  subject  is  so  vast  and  complex,  it  must  be 
concise  and  provide  a straightforward  means  of 
locating  details  of  interest  easily  and  quickly. 
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• Since  it  must  be  used  by  a wide  audience*  it  must 

be  able  to  communicate  to  a wide  variety  of  Aerospace 
Industry  n Manufacturing  personnel  as  well  as  to  Air 
Force  ICAM  Program  Office  Personnel. 

• Since  it  must  serve  as  a baseline  for  generic  subsystem 
planning,  development,  and  implementation,  it  must 
permit  sufficient  rigor  and  precision  to  insure  orderly 
and  correct  results. 

• Since  the  baseline  must  be  developed  through  the 
cooperative  effort  of  s large  segment  of  the  Aerospace 

• Industry,  it  must  include  a methodology  (rules  and 
procedures)  for  its  use  that  permit  many  diverse 
groups  to  develop  architecture  pieces  and  that  permit 
wide-spread  review,  critique,  and  approval. 

• Since  the  baseline  must  represent  the  entire  Aerospace 
Industry  rather  than  any  one  company  or  industry 
segment,  the  method  must  include  a means  of  separating 
"organization"  from  "function11}  that  is,  a common 
agreement  cannot  be  achieved  unless  the  individual 
company  organizational  differences  are  separated  out 
and  only  the  common  functional  thread  is  captured. 

The  cell-modeling  technique  selected  by  the  Air  Force  was  the  SADT 
(Structured  Analysis  and  Design  Technique)  originally  developed  in  the 
early  1970's.  The  major  subset  of  this  technique  used  by  the  ICAM  Program 
Office  was  later  re-named  "IDEFq"  . 


2. 2 IDEFo  Concepts 

The  IDEFg  methodology  has  basic  concepts  which  address  each  of 
the  needs  listed  above.  These  basic  IDEF^  concepts  are: 

I,  Cell  Modeling  Graphic  Representation.  The  "box  and 
arrow"  graphics  of  an  IDEFn  diagram  show  the  manu- 
facturing operation  as  the  box,  and  the  interfaces  to/ 
from  the  operation  as  the  arrows  entering /leaving  the 
box.  In  order  to  be  able  to  express  real-life  manu- 
facturing operations,  boxes  operate  simultaneouly 
with  other  boxes,  with  the  interface  arrows  providing 
"constraints"  as  to  when  and  how  operations  are 
triggered  and  controlled. 


Conciseness . The  documentation  of  a manufacturing 
architecture  must  be  concise  to  permit  encompassing 
the  subject  matter.  The  linear,  verbose  characteristics 
of  ordinary  language  text  is  clearly  insufficient.  The 
two-dimensional  form  provided  by  a blueprint-like 
language  has  the  desired  conciseness  without  losing 
the  ability  to  express  relationships  such  as  interfaces, 
feedback,  and  error  paths. 

Communication . There  are  several  IDEFq  concepts 
wRich  are  designed  to  enhance  communications! 

e Diagrams  based  upon  very  simple  box  and 
arrow  graphics. 

e English  textual  labels  to  describe  box  and 
arrow  meaning,  as  well  as  glossary  and  text 
to  define  precise  meaning  of  diagram  elements. 

s Gradual  exposition  of  detail,  featuring  a 

hierarchy  with  major  functions  at  the  top  and 
successive  levels  of  sub-functions  revealing 
well-bounded  detail  breakout. 

• A "node  chart"  provides  a quick  index  for 
locating  details  within  the  hierarchic  structure 
of  diagrams. 

s Limitation  of  detail  on  each  successive  diagram 
to  not  more  than  six  sub -functions  for  ease  in 
reader  comprehension, 

Rigor  and  Precision.  The  ruleB  of  IDEFq  require 
sufficient  rigor  and  precision  to  satisfy  ICAM 
architecture  needs  without  overly  constraining  the 
analyst.  IDEFq  rules  includes 

• Detail  exposition  control  at  each  level  (3-6  box 
rule) . 

• Bounded  Context  (no  omissions  or  additional 
out-of-scope  detail) . 

s Diagram  Interface  Connectivity  (Node  Numbers, 
Box  Numbers,  C-Numburs,  and  Detail  Reference 
Expression  (DRE). 

s Data  Structure  Connectivity  (ICOM  codes  and 
use  of  parentheses)  , 


• Uniqueness  of  labels  and  titles  (no  multiple 
names) . 

• Syntax  Rules  for  Graphics  (boxes  and  arrows). 

• Data  Arrow  Branch  Constraint  (Labels  for 
constraining  data  flow  on  branches)  • 

e Input  vs.  Control  Separation  (Rule  for 
determining  role  of  data), 

• Data  Arrow  Label  Requirements  (minimum 
labeling  rules). 

a Minimum  Control  of  Function  (all  functions 
require  at  least  one  control) . 

e Purpose  and  Viewpoint  (all  models  have  a 
purpose  and  viewpoint  statement) . 

5.  Methodology.  Step-by-step  procedures  are  provided  for 
modeling , review , and  integration  tasks.  Formal  courses 
for  transferring  the  methodology  are  available  for  training 
Aerospace  Industry  personnel  in  these  procedures. 

6.  Organization  vs.  Function.  The  separation  of  organization 
from  function  is  included  in  the  purpose  of  the  model,  and 
carried  out  by  the  selection  of  functions  and  interface 
names  during  model  development,  This  concept  is  taught 
in  the  IDEFq  course,  and  continual  review  during  model 
development  ensures  that  organizational  viewpoints  are 
avoided. 


2.  3 Discussion  of  Individual  IDEFo  Concepts 

In  the  remaining  sub-sections  descriptions  of  some  of  the  basic 
concepts  are  elaborated  to  clarify  them  and  show  their  utility  in  ICAM. 

2.3.1  Cell  Modeling  Graphics 

The  IDEFq  methodology  may  be  used  to  model  a wide  variety  of 
"systems",  where  a system  may  include  any  combination  of  hardware, 
software,  and  people.  For  new  systems  IDEFq  may  be  used  first  to  specify 
the  requirements  and  functions  and  then  to  design  an  implementation  that 
meets  the  requirements  and  performs  the  functions.  For  existing  systems, 
IDEFq  can  be  used  to  analyze  the  functions  the  system  performs  and  to 
record  the  mechanisms  by  which  these  are  done. 
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The  result  of  applying  IDEFq  is  a model,  A model  consists  of 
diagrams,  texts,  and  glossary,  cross-referenced  to  each  other.  Diagrams 
are  the  major  components  of  a model.  All  manufacturing  functions  and 
interfaces  are  represented  as  boxes  (functions)  and  arrows  (interfaces) 
on  diagrams. 

The  position  at  which  the  arrow  enters  a box  conveys  the  specific 
role  of  the  interface.  The  manufacturing  controls  enter  the  top  of  the 
box,  whereas  the  materials  or  information  acted  upon  by  the  manufacturing 
operation  enter  the  box  from  the  left,  resulting  in  the  output  of  the 
operation,  which  leaves  the  right-hand  side  of  the  box.  The  mechanism 
(person  or  automated  system)  which  performs  the  operation  enters  the 
bottom  of  the  box  (see  Figure  2-1), 


Inputs 


I Controls 


IMsnufscturlngj- 
Function 


Mechanism 


Outputs 

► 


Figure  2-1.  Function  Box  end  Interface  Arrows 

These  box  and  arrow  meanings  are  used  to  relate  several  sub- 
functions on  a diagram  comprising  a more  general  function.  This  diagram 
is  a "constraint  diagram"  which  shows  the  specific  interfaces  which 
constrain  each  sub-function,  as  well  aB  the  sources  and  targets  of  the 
interface  conatraints  (see  Figure  2-2). 
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Figure  2-2.  Constraint  Diagrams 
(Function  B is  constrained  by  ons  input  and  two  controls,  and 
produces  a single  output,  which  constrains  Function  C). 


Here,  the  term  "constrains"  means  that  a function  uses  the  material 
or  information  shown  entering  the  box,  and,  therefore,  is  constrained  from 
operating  by  the  interface  i the  function  cannot  act  until  the  contents  of 
the  interface  arrow  is  provided,  and  the  way  in  which  the  function  operates 
depends  upon  the  details  (value,  number,  etc.)  of  the  contents  of  the 
interface  arrow. 

2.3.2  Communication  by  Gradual  Exposition  of  Detail 

One  of  the  most  important  features  of  IDEF^  Is  that  it  gradually 
introduces  greater  and  greater  levels  of  detail  through  the  diagram 
structure  comprising  the  model.  In  this  way,  communication  is  enhanced 
by  providing  the  reader  with  a well-bounded  topic  with  a manageable 
amount  of  new  Information  to  learn  from  each  diagram. 

The  structure  of  an  IDEF^  model  is  shown  in  Figure  2-3.  Here,  a 
series  of  four  diagrams  is  shown  with  each  diagram's  relation  to  the  others. 
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An  IDEFg  model  starts  by  representing  the  whole  system  as  a simple 
unit  — a box  with  arrow  interfaces  to  functions  outside  the  system.  Since 
the  single  box  represents  the  system  as  a whole,  the  descriptive  name 
written  in  the  box  is  general.  The  same  ie  true  of  the  interface  arrows 
since  they  also  represent  the  complete  sat  of  external  interfaces  to  the 
system  as  a whole. 

The  box  that  represents  the  system  aa  a single  module  Is  then 
detailed  on  another  diagram  with  boxes  connected  by  interface  arrow*, 

These  boxes  represent  major  sub-functions  (submodules)  of  the  single 
parent  module.  This  decomposition  reveals  a complete  set  of  submodules, 
each  represented  as  a box  whoae  boundaries  are  defined  by  the  interface 
arrows.  Each  of  these  submodule  boxes  may  be  similarly  decomposed  to 
expose  even  more  detail. 

IDEFq  provides  rules  to  introduce  further  detail  during  decomposi- 
tion. A module  is  always  divided  into  no  fewer  than  three,  but  no  more 
than  six  submodules.  The  upper  limit  of  six  forces  the  use  of  a hierarchy 
to  describe  complex  subjects  • The  lower  limit  of  three  insures  that  enough 
detail  is  introduced  to  make  the  decomposition  of  interest, 

Each  diagram  in  a model  is  shown  in  precise  relationship  to  other 
diagrams  by  means  of  interconnecting  arrows.  When  s module  is  decomposed 
into  submodules,  the  interface  between  the  submodules  are  shown  as 
arrows.  The  name  of  each  submodule  box  plus  its  labeled  interfaces  define 
a bounded  context  for  that  submodule. 

In  all  cases,  every  submodule  is  restricted  to  contain  only  those 
elements  that  lie  within  the  scope  of  its  parent  module.  Further,  the 
module  cannot  omit  any  elements.  Thua,  aa  already  Indicated,  the  parent 
box  and  its  interfaces  provide  a context.  Nothing  may  be  added  or  removed 
from  this  precise  boundary. 


2.3.3  Disciplined  Teamwork 


The  IDEFq  methodology  includes  procedures  for  developing  and 
critiquing  models  by  a large  group  of  people,  as  well  as  integrating 
support  subsystems  into  an  XDEFq  Architecture,  Additional  supporting 
procedures  such  as  librarian  rules  and  procedures,  are  also  included  in 
the  IDEF^  methodology.  (It  should  be  noted  that  some  of  these  rules  and 
procedures,  such  as  the  Kit  Cycle  critique  procedure,  are  also 
used  with  other  IDEF  techniques.) 

The  creation  of  an  IDEFq  model  is  the  most  basic  of  these 
"disciplined  teamwork"  procedures.  The  creation  of  a model  is  a dynamic 
process  which  usually  requires  the  participation  of  more  than  one  person. 
Throughout  a project,  authors  create  initial  diagrams  which  are  distributed 
to  project  members  for  review  and  comment,  The  discipline  requires  that 
each  person  expected  to  make  comments  about  a diagram  shall  make  them  in 
writing  and  submit  them  to  the  author  of  the  diagram.  This  cycle  continues 
until  the  diagrams,  and  eventually,  the  entire  model,  are  officially  accepted. 

IDEF  includes  procedures  for  retaining  written  records  of  all 
decisions  and  alternate  approachea  as  they  unfold  during  the  project, 

Copies  of  the  diagrams  crested  by  an  author  are  critiqued  by  knowledgeable 
commentera  who  document  auggeations  directly  onto  the  copies,  Authors 
respond  to  each  comment  in  writing  on  the  same  copy.  Suggestions  are 
accepted  or  rejected  in  writing  along  with  the  reasoning  used.  As  changes 
and  corrections  are  made,  outdated  veraiona  of  diagrams  are  retained  In 
the  project  files. 

The  diagrams  are  changed  to  reflect  corrections  and  commenta.  More 
detail  ia  added  to  the  model  by  the  creation  of  more  diagrams  which  also 
are  reviewed  and  changed . The  final  model  represents  an  agraemsnt  on  a 
representation  of  the  system  from  a given  viewpoint  and  for  a given  purpoae. 
This  representation  can  be  easily  read  by  others  outside  the  initial  project, 
used  for  presenting  the  system  definition  in  short  stand-up  briefings  or  in 
week  long  walkthroughs , and  for  organizing  new  projects  to  work  on  system 
changes. 
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SECTION  3 

UNDERSTANDING  IDEF0  DIAGRAMS 
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CONTROL 


OUTPUT 
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UNDERSTANDING  IDEFq  DIAGRAMS 

; A modal  ia  a representation  of  a ayatam.  It  may  daacribe  what  a 

| ay  item  ia,  what  It  doea,  or  what  thlnga  It  worka  on, 

l 

i Syatema  are  compoaad  of  interfacing  or  interdependent  parts  that 

i I 

{ work  together  to  perform  a uaeful  function,  The  parta  may  be  anything,  j 

Including  machinery,  information,  objects,  proceaaea,  aoftware,  or  people,  j 

IDEFq  can  be  uaed  to  deacrlbe  functions  performed  by  syatema  or  parta  of 

systems  and  the  information  or  things  through  which  the  functions  interface,  ] 

IDEFq  represents  a system  by  means  of  a model  compoaed  of  diagrams , 
text,  and  glossary.  Diagrams  are  composed  simply  of  boxes  and  arrows . j 

In  these  diagrams,  the  boxea  represent  activities  and  arrows  represent  | 

I things  processed  by  the  system,  j 

i ! 

3.1  IDEFq  Symbol! 

i 

j 3.1.1  Diagrams 

I A model  is  a series  of  diagrams  with  supportive  documentation  that 

; ' | 
break  a complex  subject  into  its  component  parts.  The  initial  diagram  is 

the  moat  general  or  abstract  description  of  the  whole  system.  This  1 

' 

diagram  shows  each  major  component  as  a box.  The  details  of  each  major  j 

component  are  shown  on  other  diagrams  as  boxes.  These  boxes  can  be 
broken  down  into  still  more  diagrams,  until  the  system  is  described  to 
any  desired  level  of  detail. 

Each  detailed  diagram  is  the  decomposition  of  s box  on  a more 
general  diagram.  At  each  step,  the  general  diagram  ia  sa  d to  be  the 
"parent"  of  the  detailed  diagram.  A detailed  diagram  la  beat  thought  of 
aa  fitting  "iniide"  a parent  box.  (See  Figure  3-1.) 

'V 


Boxes  represent  system  functions  (activities,  actions,  processes 
or  operations)  and  arrows  represent  data  (either  information  or  objects). 

A oox  on  the  upper  diagram  is  detailed  by  the  boxes  and  arrows  of  the 
lower  diagram.  Arrows  entering  and  leaving  the  upper  box  are  exactly 
those  arrows  entering  and  leaving  the  lower  diagram,  because  both  the 
box  and  the  diagram  represent  exactly  the  same  part  of  the  system, 

A fundamental  principle  of  IDEFq  is  that  a diagram  cannot  have 
fewer  than  three  nor  more  than  six  boxes.  This  approach  ensures  uniform, 
systematic  exposition  of  successive  levels  of  detail.  The  upper  limit  of 
six  was  chosen  since  physchological  experiments  have  shown  that  it  is 
difficult  to  grasp  more  than  5-7  distinct  concepts  at  one  time.  The  lower 
limit  of  three  was  chosen  to  insure  that  enough  detail  is  introduced  to  make 
the  decomposition  meaningful,  High-level  diagrams  encompass  a wide 
range  of  detail  so  that  words  on  the  boxes  and  arrows  must  be  abstract 
and  describe  general  concepts.  Successive  diagrams  at  lower  levels 
gradually  reveal  this  detail,  using  more  specific  terms,  one  step  at  a time, 

3.1.2  Boxes 

Boxes  on  a diagram  represent  functions.  Functions  show  what 
must  be  accomplished  without  Identifying  any  other  necessary  aspect  such 
as  needs  or  means,  Functions  are  described  by  an  active  verb  phrase 
written  inside  the  box.  Each  box  on  a diagram  is  numbered  in  its  lower 
right  corner,  in  order  from  "1"  to  at  most  "6," 

A function  is  anything  that  can  be  named  with  an  active  verb  phrase . 
This  includes  everything  from  the  concrete  to  the  conceptual,  such  ast 

tighten  assemble  classify  adapt 

attach  transcribe  construct  resolve 

measure  evaluate  solve  develop 

Such  functions  occur  over  periods  of  time,  Functions  are  not  expressed 
as  nouns,  such  as  "maintenance , " 


3.1,3  Box /Arrow  Relationship 


The  arrows  that  connect  to  a box  represent  objects  or  infor- 
mation needed  by  or  produced  by  the  function.  They  are  each  labeled 
with  a*noun  phrase,  written  beside  the  arrow.  “Data11  may  be  information, 
objects,  or  anything  that  can  be  described  with  a noun  phrase.  The 
arrows  are  constraints  that  define  the  boxes,  not  sequencss  or  flows  of 
functions  (Figure  3-2). 

The  aide  of  tjie  box  at  which  an  arrow  enters  or  leaves  shows  the 
arrow's  role  as  an  input,  a control  or  an  output.  Incoming  arrows  (left 
and  top  of  box)  show  the  data  needed  to  perform  the  function,  Outgoing 
arrows  (right  of  box)  show  the  data  created  when  the  function  is  performed. 
From  left  to  right  (input  to  output),  a function  transforms  data.  An  input 
ia  converted  by  the  function  into  the  output.  Tha  terms  input  and  output 
convey  the  notion  that  a box  represents  a transition  from  a "before"  to  an 
"after"  state  of  affairs. 


These  data  are 

needed  to  do  the  j 
Function 

i- 

This  date  Is 
produced  by 
doing  the 
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/ , 

pi  iKir 

ITION 

Figure  3-2.  Arrows  Clarify  and  Bound  tha  Meaning  of  Each  Box 

A control  describes  the  conditions  or  circumstances  that  govern 
the  function.  The  roles  of  input  and  control  are  different.  The 
distinction  is  important  to  understanding  the  operation  of  systems.  The 
assumption  is  that  "an  arrow  is  a control  unless  it  obviously  serves  only 
as  input."  Every  function  box  will  have  at  least  one  control  arrow. 
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The  bottom  of  a box  is  reserved  to  indicate  a mechanism,  which  may 
bo  the  person  or  device  which  carries  out  the  function.  The  input  and 
output  shows  WHAT  is  done  by  the  function,  the  control  shows  WHY  it  is 
done,  and  the  mechanism  shows  HOW  it  is  done.  (Figure  3-3), 
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Figure  3-3.  Box /Arrow  Relationship 

Boxes  represent  collections  of  related  functions,  not  just  monolithic 
actions.  A box  may  perform  various  parts  of  its  function  under  different 
circumstances,  using  different  combinations  of  its  input  and  controls  and 
producing  different  outputs.  These  are  called  the  different  activations 
of  the  box.  There  may  be  several  arrows  on  any  one  aide  of  a box  which 
muy  indicate  different  activations. 

If  it  is  unclear  whether  a particular  word  is  a noun  (data)  or  a 
verb  (function),  an  "(n)"  or  "(v)"  may  be  appended  to  the  word.  For 
example,  the  word  "Record"  could  mean  a record,  or  the  action  of 
recording.  "Record  ( n ) " is  used  for  the  former  case,  and  "Record  (v)" 
is  used  for  the  latter. 

The  arrows  on  an  IDEFq  diagram  represent  data  constraints. 

They  do  not  represent  flow  or  sequence.  Connecting  the  output  of  one 
box  to  the  input  or  control  of  another  box  shows  a constraint . (Figure  3-4)  . 
The  box  receiving  the  data  is  constrained,  since  the  function  cannot  be 
performed  until  the  data  is  made  available  by  the  box  that  produces  it. 

The  arrows  entering  a box  show  all  the  data  that  is  needed  for  the  function 
to  be  performed. 
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Figur .*  3-4.  Meaning  tr  Constraint 

Several  functions  on  a single  diagram  could  be  performed  simul- 
taneously, If  the  needed  constraints  have  been  satisfied.  Arrows  connect 
boxes,  and  an  output  of  one  box  may  provide  some  ,n  of  the  data 
needed  by  one  or  more  other  boxes.  (Figure  3-5) . 
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Figure  3-5.  Simultaneous  Action 
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Neither  sequence  nor  time  is  explicit  in  IDEF^  diagrams.  Feedback, 
iteration,  continuous  processes,  and  overlapping  (in  time)  functions  are 
easily  shown  by  arrows.  (Figure  3-6).  The  arrows  connecting  the  left 
("input")  or  top  ("control')  of  a box  are  constraints,  They  represent 
data  or  objects  needed  to  perform  some  part  of  the  function.  For  example, 
a draft  system  specification  submitted  for  review  may  be  approved  and 
thus  become  final,  or  it  may  be  returned  with  comments  and  with  a request 
that  a nesv  draft  be  submitted.  The  latter  reactivates  the  design  function. 
Both  the  design  and  the  review  are  done  with  respect  to  the  system 
requirements . 


mm 

aBPWM 

■5 

■ 

■ 

■D5a 

II  i 

1 

w 

m 

■ 

muB 

Figure  3-6.  Example  of  Feedback 

Arrows  may  branch  (implying  that  the  same  data  is  needed  by  more 
than  one  function)  or  they  may  join  (implying  that  the  same  class  of  data 
may  be  produced  by  more  than  one  function) . The  branches  may  each 
represent  the  same  thing,  or  different  things  of  the  same  general  type. 
Labels  state  what  the  arrows  represent.  The  labels  on  branches  and  joins 
provide  a detailing  of  the  content  of  the  more  general  arrow  just  as  lower 
level  diagrams  provide  detailing  of  boxes. 


Data  arrows,  like  function  boxes,  represent  categories.  It  ia 
useful  to  think  of  high  level  data  arrows  as  "pipelines"  or  "conduit*." 
High  level  arrows  have  general  labels.  If  they  branch,  each  branch  will 
have  a more  specific  label.  (Figure  3-?) . Arrow  labels  must  convey  the 
author's  intent  to  the  reader.  Using  fewer  arrows  will  reduce  clutter  and 
make  a diagram  easier  to  understand  but  requires  careful  choice  of 
meaningful  words  to  convey  the  message. 


Figure  3-7.  Example  of  Arrow  Branching 

On  any  given  diagram,  data  may  be  represented  by  an  internal 
arrow  (both  ends  connected  to  boxes  shown  on  the  diagram)  or  a 
boundary  arrow  (one  end  unconnected,  implying  production  by  or  use 
by  a function  outside  the  scope  of  the  diagram). 


3. 1.3.1  Arrow  Connection!  Between  Boxes 


To  form  a complete  diagram,  from  three  to  six  boxes  are  drawn  and 
connected  by  input,  output,  and  control  arrows.  Any  output  arrow  may 
provide  some  or  all  of  the  input  or  control  (or  mechanism)  to  any  other 
box.  All  manner  of  arrow  branches  and  joins  are  used  to  show  box 
relationships.  An  output  arrow  may  branch  and  provide  data  to  several 
boxes,  Arrows  that  are  unconnected  at  one  end  represent  data  that  la 
supplied  or  consumed  outside  the  scope  of  the  diagram. 


(box  3).  art  reflected  on  "invoices. " 


Figure  3-8.  Arrow  Connections 


3.1. 3.2  Mechanism  Arrows 

A box  represents  a function.  The  input  data  (on  the  left)  are 
transformed  into  output  data  (on  the  right).  Controls  (on  the  top)  govern 
the  way  the  function  ia  done.  Mechanisms  (on  the  bottom)  Indicate  the 
means  by  which  the  function  in  performed.  (Figure  3-9).  A "mechanism" 
might  be  a person  or  a computer  or  a machine  or  some  other  device  which 
aids  in  carrying  out  the  function.  The  box  itself,  with  its  inputs, 
controls,  and  outputs  indicates  WHAT  the  system  does.  The  mechanism 
shows  HOW  that  function  is  accomplished.  Diagrams  drawn  without 
mechanisms  show  what  functions  a system  must  perform.  Mechanisms  will 
specify  how  those  functions  are  to  be  performed. 
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Figure  3-9.  Example  of  Mechanism 

A downward-pointing  mechanism  arrow  (known  as  a "call")  indicate* 
a "system"  that  completely  performs  the  function  of  the  box.  If  there  is  a 
need  for  further  detailing,  it  will  be  found  in  a separate  model  of  the 
mechaniem  Itself.  (Figure  3-10). 


Figure  3-10.  Illustration  of  Mechanism  Model  Cells 

Mechanism  arrows  mey  be  the  output  of  other  boxes,  if  those 
functions  create  or  prepare  devices  from  their  inputs  and  controls. 
(Figure  3-11). 


Figure  3-11.  Example  of  an  Output  that  Becomes  e Mechanism 
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3.1.4  An  Example  of  en  IPEF^  Diagram 

Figure  3-12  is  a complete  IDEF^  diagram  taken  from  the  Function 
Model  of  "Manufacture  Product  (MFGO)." 

The  three  boxes  of  A612  (Figure  3-13)  are  a decomposition  of  Box  2 
of  A61  "Control  Production  Orders."  Baaed  on  production  requirements 
and  existing  shop  loads,  an  expected  load  is  forecast  (Box  1 of  A612). 

Given  the  1)  expected  load,  2)  shop's  oapacity,  and  3)  specific  stop 
orders,  adjustments  to  the  schedule  are  Identified  in  Box  2.  The  schedule 
is  then  actually  adjusted  (Box  3). 

Note  that  a single  box  may  perform  its  function  under  different 
circumstances.  Box  1 may  occur  even  if  there  are  no  "revised  order 
release  datea"  provided  by  Box  3>  Or  it  may  occur  when  "revised  order 
release  dates"  are  provided,  even  though  "production  requirements"  and 
"shop  load  status"  have  not  changed.  These  different  occurrences  are 
known  as  different  activations  of  a box.  They  may  be  formally  specified 
but  in  many  cases  will  be  naturally  and  intuitively  understood  by  anyone 
familiar  with  the  box  and  arrow  notation.  For  example,  Box  2 can  occur 
even  if  "stop  orders  and  material  shortage  reports"  are  absent.  Also  Box  3 
does  not  produce  "problems"  with  every  occurrence. 
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3.2  Additional  Symbola 

Further  notation  is  needed  to  structure  diagrams  so  that  they  form 
a coherent,  consistent  model. 

To  create  a model  composed  of  diagrams,  FEO's,  text,  and  glossary, 
we  need  toi 

a Indicate  the  position  of  each  diagram  in  a model 

and  the  supportive  documentation  associated  with 
each  diagram.  This  will  be  done  with  reference 
expressions  > 

s indicate  the  connection  of  boundary  arrows  to 

arrows  of  the  parent  diagram.  This  will  be  done 
with  ICOM  codiai 

• auppresa  unnecessary  detail.  This  will  be  done 
with  tunnelled  arrows. 

These  conventions  fill  out  the  set  of  symbols  that  enable  diagrams  to 
accurately  reflect  real  system  functions. 

3.2.1  Refer* nca  Exprsaslons 

3.2. 1.1  Node  N umbera 

As  explained  in  Section  3.1.1,  each  diagram  is  limited  to  three  to 
six  boxue.  Each  box  on  a diagram  is  numbered.  A box  on  any  diagram 
may  be  further  described  by  a "lower"  diagram  which  may  also  be  further 
detailed  In  more  diagrams.  This  forms  a hierarchy  of  diagrams. 

Node  numbers  are  used  to  indicate  the  position  of  any  diagram  or 
box  in  the  hierarchy.  For  example,  A 21  is  the  diagram  that  details  box  1 
on  the  A2  diagrem.  Similarly,  A2  details  box  2 on  the  AO  diagram  which  is  . 
the  top-moat  complete  diagram  of  a model.  This  hierarchy  may  be  shown  in 
a chart  of  diagram  names  and  node  numbers  catled  a node  tree.  Figure  3-14 
le  a typical  node  tree. 
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Figure  3-14.  Diagrams  form  o "Hierarchy"  shown  by  s Noda  True 

All  node  numbers  of  IDEFQ  diagrams  begin  with  the  letter  A,  which 
identifies  them  as  "Activity"  or  function  diagrams*  A one-box  diagram  is 
provided  as  the  "context"  or  parent  of  the  whole  model.  By  convention, 
the  diagram  hns  the  node  number  "A-0"  (A  minus  Aero).  If  a full  diagram 
la  provided  to  make  the  context  of  the  A-0  complete,  that  is  numbered 
"A-l."  This  can,  if  necessary,  proceed  upwird.  Some  uomplex  subjects 
have  actually  started  with  "A-4,"  even  though  A-0  is  still  the  "top"  of 
the  model,  An  example  of  this  can  be  found  in  the  Function  Model  of 
"Manufacture  Product"  (MFGO),  Volume  VII  of  this  report. 


Other  node  numbers  are  sometimes  used.  A "FEO"  ("For  Exposition 
Only")  diagram  is  any  diagram  that  falls  outside  the  strict  hierarchy. 

FEO's  may  contain  more  than  six  boxes,  partial  arrow  structures,  or 
anything  needed  by  an  author  to  illustrate  a point.  Node  numbers  for 
FEO's  contain  "F"  (e.g.,  A2F).  Glossary  definitions  support  diagrams. 
Node  numbers  for  a glossary  contain  "G"  (e.g.,  A1G).  Text  numbers 
contain  "T"  and  follow  the  node  number  of  the  diagram  with  which  they 
are  aaaociated  (e.g.,  A2T).  There  may  be  more  then  one  FEO  or  glossary 
(e.g.  i A2F1,  A2F2,  .<•),  but  there  should  be  no  more  than  one  page  of 
text  associated  with  a given  diagram.  (Text,  FEO's  and  Glossary  are 
explained  in  Section  6.) 

Node  numbers  are  also  «<sati  to  Indicate  the  decomposition  of  a 
box  In  a diagram,  If  s box  has  been  decomposed,  the  node  number  of 
the  diagram  which  represents  the  decomposition  is  written  outside  the  box 
under  the  right  hand  corner,  In  Figure  3-15,  the  reference  expression 
under  boxes  1 and  2 Indicate  that  they  have  been  decompoaed. 

3.2, 1.2  Model  Names  end  Node  Numbers 

Each  model  haa  s name,  which  should  bo  chosen  for  maximum 
clarity  to  distinguish  it  from  other  models.  For  example! 

TOPIC 

Diagramu  In  the  model  are  referred  to  by  adding  a slash  and  the  node 
number  to  the  model  name.  For  example! 

T0PIC/A3 

It  Is  this  form  which  is  usually  written  as  the  complete  node  number  of 
each  diagram  of  a model. 


Boundary  arrows  at  the  A-0  level  are  called  external  ■-  rrowa  because 
the  A-0  diagram  establishes  the  context  of  the  model  and  all  arrows  related 
between  the  model  and  that  which  is  extern al  to  the  context  or  scope  of 
the  model. 

3.2.3  Coding  Boundary  Arrows 

A specific  notation,  called  ICOM  code*,  specifies  the  matching 
connections.  The  letter  I.  C,  0,  or  M is  written  near  the  unconnected 
end  of  each  boundary  arrow  on  the  detail  diagram.  This  identifies  that 
the  arrow  is  shown  as  an  Input,  Control,  Output,  or  Mechanism  on  the 
parent  box.  This  letter  is  followed  by  a number  giving  the  position  at 
which  the  arrow  is  shown  entering  or  leaving  the  parent  box,  numbering 
left  to  right  and  top  to  bottom,  For  example,  "C3"  written  on  an  arrow 
In  the  detail  diagram  indicates  that  this  arrow  corresponds  to  the  third 
control  arrow  entering  the  parent  box. 

This  coding  relates  each  diagram  to  its  own  parent.  New  codas  are 
assigned  when  the  detail  diagram  becomes  a parent  diagram  through 
decomposition.  Using  this  letter-number  nhatching  scheme',  an  arrow 
shown  as  control  or  as  input  on  a parent  diagram  is'  not  limited  to  the  . 
same  role  on  a detail  diagram.  In  Fig"ure  3-18,  C2  on  the  parent 
box  appears  as  an  input  to  box  1 on  its  detail  diagram.  ICOM  codes  must 
be  written  at  the  unconnected  ends  of  all  boundary  arrows  except  for 
the  very  topmost  diagram  In  a model,  and  on  tunneled  arrows. 


37 


I 


Figure  3-18.  Codes  are  Written  on  the  Detail  Diagram 
3.2.5  Tunnelled  Arrows 

Tunnelled  arrows  indicate  that  the  data  conveyed  by  these  arrowa 
was  riot  telovant  to  a particular  level  of  detail. 


■ill 


~C  h-* 
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Figure  3-19.  Tunnelled  Arrows  at  Connected  End 

Tunnelling  an  arrow  where  It  connects  to  a oox  (Figure  3-191 
indicates  that  the  data  conveyed  is  not  necessary  at  the  next  level  of 
decomposition . 
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Figure  3-20.  Tunnelled  Arrow*  at  Unconnected  End* 

Tunnelling  an  arrow  at  the  unconnected  end  (Figure  3-20)  indicates 
that  the  data  conveyed  i*  not  relevant  to  or  supplied  b/  the  parent, 
diagram. 

Parenthesizing  the  unconnected  end*  says,  "This  arrow  does  not 
appear  in  the  parent  diagram.  It  ha*  no  ICOM  code."  Paren- 
thesizing the  end  where  the  arrow  connects  to  the  box  says,  "This  arrow 
does  not  appear  in  detail  diagrams.  Its  ICOM  code  is  not  tracked  from 
here  on  and  may  never  be  explicitly  referenced. " It  is  possible  for  an 
arrow  to  have  a parenthesized  arrowhead,  disappear  for  one  or  more 
levels  of  detail,  and  then  be  reintroduced  at  some  specific  level  of 
detail  with  a parenthesized  end.  If  the  original  source  or  destination  is 
known,  that  too  should  be  noted  with  the  appropriate  reference 
expression,  written  beside  the  parentheses. 


3.2.6  An  Example  of  Decomposition 


i 


i 


i 


i 


! 


I 


I 

I 


I 


Using  tlie  Function  Model  of  "Manufacture  Product"  (MFGO),  it  is 
possible  to  view  the  overall  function  of  "Manufacture  Product"  as  being 
composed  of  the  following  subfunctions  i 

• Plan  for  Manufacture 

• Make  and  Administer  Schedules  and  Budgets 

• Plan  Production 

• Provide  Production  Resources 

• Obtain  Manufacturing  Materials 

• Produce  Product 

Any  of  these  may  then  be  further  subdivided.  "Plan  for  Manu- 
facture" may  contain  the  subfunctlonsi 

• Assume  a Structure  and  Method  of  Manufacture 

a Estimate  Requirements,  Cost,  Time  to  Produce 
e Develop  Production  Plans 

• Develop  Support  Activities  Plans 

Each  of  these  subfunctions  may  be  divided  again  to  the  limits  of  usefulness, 
knowledge,  or  time  available. 

This  structure  of  functions  and  subfunctions  may  be  shown  as  a 
"node  tree."  (Figure  3-22). 
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Fiflur*  3-22.  Nod*  Tr** 

The  atructure  of  function*  and  aubfunctiona  may  alao  bo  ahown  aa 
a "node  index."  (Figure  3-23).  Thia  index  format  ia  aimilar  to  the  format 
of  a table  of  content*  and  to  the  format  of  an  "indentured  part*  liat" 

(bill  of  material*)  uaed  in  manufacturing  and  engineering. 

AO  Manufacture  Product 

A1  Plan  for  Manufacture 

All  Aaaume  a Structure  and  Method  of  Mfg. 

A 12  Eatimate  Requirement*,  Coat,  Time  to  Produce 
A 13  Develop  Production  Plana 

A 14  Develop  Support  Activities  Plan 

A 2 ... 


Figure  3-23.  Nod*  Index 


The  following  IDEFq  diagram*  begin  with  the  «*me  aubject  found  at 
the  top  of  the  "node  tree."  Figure  3-24,  A-0,  ahowa  information  and 
objects  that  bound  what  we  mean  by  "Manufacture  Product."  The  A-0 
diagram  establishes  a context  for  describing  "Manufacture  Product." 
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Figure  3-24.  A-0,  Manufacture  Product 
"Manufacture  Product"  includes  everything  that  starts  with  the 
inputs  and  Controls  i 

Procurable  Items 
Product  Design 

Product  Manufacturing  Requirements 

and  finishes  with  the  Outputs) 

Manufacturing  Capability  Information 
Product,  Parts,  Prototypes 
Production  Data 
Manufacturing  Information 
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What  happens  within  the  box  ahown  on  A-0,  'Manufacture  Product, 
la  ahown  on  the  AO  diagram,  which  has  the  same  title. 
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MANUFACTURE  PRODUCT 


Figure  3-25.  AO,  Manufacture  Product 

Each  function  that  is  part  of  "Manufacture  Product"  ia  a recognisable 
grouping  of  detailed  decisions  and  actions  selected  from  the  complex  fabric 
of  manufacturing.  The  function  grouping*  are  definod  by  their  data 
relationships,  that  ia.  the  information  and  objects  that  pass  betwean  the 
functions.  These  relationships  define  the  boundaries  of  a function  and 
the  terminology  used  to  name  each  function. 


"’0 ' V.-Ix,'1. 


Any  of  the  boxes  on  AO  may  be  further  described  with  another 
diagram.  The  first  box  of  AO  ia  detailed  in  A 1 "Plan  for  Manufacture". 
A1  shows  only  the  functions  and  data  that  are  part  of  "Plan  for  Manu- 
facture" as  defined  by  the  arrows  appearing  on  AO, 


Figure  3-26.  A1,  Plan  for  Manufacture 
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READING  IDEFq  DIAGRAMS 


A model  la  made  up  of  a aeries  of  diagrams  and  associated  materials 
arranged  in  hierarchic  manner.  A node  index  or  table  of  contents  must 
be  provided.  Placing  the  diagrams  in  hierarchical  order  gives  an  overall 
view  of  the  model  and  allows  access  to  any  portion. 

Reading  is  done  top-down.  After  the  top  levels  are  read,  first 
level  diagrams  are  read,  then  second  level  diagrams  are  road,  etc.  If 
specific  details  about  a modal  are  needed,  the  node  index  is  used  to 
descend  through  the  levels  to  the  required  detail. 

When  published,  a model  is  hound  in  "page-pair"  format  and  "node 
index"  order,  "Page-pair"  format  means  thst  each  diagram  and  the  entire 
text  associated  with  it  appear  on  a pair  of  facing  pagea. 


Figure  4-1.  Page-Pair  Format 


"Node  index"  order  means  that  all  detail  diagrams  relating  to  ono 
box  on  a diagram  are  presented  before  the  details  of  the  next  box.  This 
places  related  diagrams  together  in  the  same  order  used  in  an  ordinary 
table  of  contents. 


AO  Plan  for  Manufacture 
A1  Assume  a Structure  and  Method  of  Mfg. 

A 2 Estimate  Requirements,  Coat,  Time  to  Produce 
A21  Estimate  Resource  Needs 
A22  Estimate  Costa  to  Purchase  or  Miake 
A 23  Estimate  Timing  for  Startup  and  Production 
A3  Develop  Production  Plana 
A 4 Develop  Support  Activities  Plan 

▼ 


Order  of 
diagrama  in 
a document 


Figure  4-2.  Node  Index  Showing  Diagram  Order 


4. 1 Approaching  a Model 

Models  provide  an  overview  of  the  whole  system  as  well  as  details 
of  a particular  subject.  To  read  a model  for  its  overview,  use  the  index 
to  find  all  high-level  diagrams. 


AO  Manufacture  Product 
A 1 Plan  for  Manufacture 

All  Assume  a Structure'  & Method  of  Mfg,' 

A 12  Estimate  Requirements,  Time,  Coat  to  Produce 
A 13  Develop  Production  Plans 

A 14  Develop  Support  Activities  Plan 

j"  AS  Make  & Aqmlmster'15cho3uIes  It  Budgets 
A 21  Develop  Master  Schedule 
A 22  Develop  Coordinating  Schedule 
A 23  Estimate  Costa  l Make  Budgets 
A24  Monitor  Performance  to  Schedule  * Budget 
| A 3 Plan  Production 


Figure  4-3.  Noda  Index  Showing  Ovsrvlsw  Diagrams 

To  read  a model  for  detail,  use  the  index  to  find  all  diagrams  detailing  the 
subject  of  Interest, 


AO  Manufacture  Product 
A1  Plan  for  Manufacture 
All  Asaume  a Structure  & Method  of  Mfg, 

A 12  Estimate  Requirements,  Time,  Cost  to  Produce 
A 13  Develop  Production  Plans 
A 14  Develop  Support  Activltlee  Plan 
A2  Make  I Administer  Schedules  I Budgets 
A21  Develop  Master  Schedule 
A 22  Develop  Coordinating  Schedule 
A23  Estimate  Costa  t Make  Budgets 
A24  Monitor  Performance  to  Schedule  4 Budget 
A3  Plan'troduction 


Figure  4-4.  Node  Index  Showing  Specific  Detail  Diagrams 
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Further  detailing  in  a model  may  be  traced  by  referring  to  the 
reference  expression  just  below  the  box  number.  This  indicates  either 
the  node  number  or  page  number  of  the  detail  diagram  for  that  box.  If 
no  reference  expression  appears . the  box  has  not  yet  been  detailed. 


For  example*  on  diagram  A 24 


are  found  on  diagrams  with  node  numoer  A243. 


means  that  the  details  of  box  3 


Details  may  be  shared  within  a model  or  found  in  a different 
model.  In  this  case,  a down  arrow  indicates  where  the  shared  detailing 
appears.  (See  Page  3-10) . ■ 

^ MQ/A4 

Box  4 is  detailed  in  model  MQ  by  diagram  A4.  (This  is  known  as  a "call.11) 


1 


4.2  Diagram  Reading  Steps  j 

i 

The  precise  information  about  a system  is  in  the  diagrams  them-  ; 

selves.  The  following  reading  sequence  is  recommended)  , 

1.  Scan  the  boxes  of  the  diagram  to  gain  an  impression 
of  what  is  being  described, 

2.  Refer  back  to  the  parent  diagram  and  note  the  arrow 
connectione  to  the  diagram,  Try  to  identify  a "most 
important"  Input,  control  and  an  output, 

3.  Consider  the  arrows  of  the  current  diagram . Try 

to  determine  if  there  is  a main  path  linking  the  "most 
important"  input  or  control  and  the  "meet  important" 
output. 

r 

4.  Mentally  walk  through  the  diagram,  from  upper  left  'j 

to  lower  right,  using  the  main  path  as  a guide.  Note  v 

how  other  arrows  interact  with  each  box.  Determine  I 

if  there  are  secondary  paths.  Check  the  etory  , 

being  told  by  the  diagram  by  considering  how  familiar 

situations  are  handled.  j 

5.  Check  to  see  If  a related  "FEO"  diagram  exists. 

6.  Finally,  read  the  text  and  glossary  if  provided.  1 

! 

,'r 
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This  sequence  ensures  that  the  major  features  of  each  diagram  receive 
attention.  The  text  will  call  attention  to  anything  that  the  author  wishes 

to  emphasise.  The  glossary  will  define  the  author's  interpretation  of  the 

\ 

.terminology  used. 

Each  diagram  has  a central  theme,  running  from  the  most  important 
incoming  boundary  arrow  to  the  most  important  outgoing  boundary  arrow. 
This  main  path  through  the  boxes  and  arrows  outlines  the  primary  function 
of  the  diagram.  Other  parts  of  the  diagram  represent  qualifying  or 
alternative  conditions  which  are  secondary  to  the  main  path. 

The  system's  operation  can  be  mentally  envisioned  by  pursuing 
the  main  path.  Specific  kinds  of  data  inputs,  the  handling  of  errors, 
and  possible  alternative  outputs  lend  detail  to  the  story.  This  walk- 
through enhances  understanding  of  the  diagrams. 
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Only  that  which  la  explicitly  stated  is  necessarily 
implied. 


This  derives  from  Che  very  nature  of  constraint  diagrams.  Unspeci- 
fied constraints  must  not  be  assumed)  necessary  constraints  must  be 
explicit. 


The  corollary  is  that! 


Any  further  detailing  not  explicitly  prohibited  Is 
implicitly  allowed. 


Figure  4-6.  Example  of  Constraint 

An  assumption  can  be  made  using  Figure  4-6  that  the  temperature  is 
measured  "often  enough"  and  the  tolerances  are  changed  "when  appropriate" 
and  the  temperature  Is  monitored  against  the  tolerances  "often  enough" 
that  the  danger  signal  will  be  produced  "soon  enough."  None  of  these 
intuitive  understandings  would  conflict  with  subsequent  detailing  which 
showed  that  i 

a.  the  temperature  was  measured  by  periodic  sampling,  or 

b.  current  tolerances  were  requested  only  when  the 
temperature  increased  by  some  fixed  amount,  or 


c.  a series  of  temperature  values  produced  by  box  1 
was  stored  by  box  2 which  examined  the  pattern 
of  change  to  determine  if  the  pattern  was  within 
the  tolerances, 

d.  etc. , etc . 

The  graphic  notations  of  a diagram  are,  by  themselves,  abstract. 
However  they  do  make  important  fundamental  distinctions.  Their 
abstract  nature  should  not  detract  from  the  intended  breadth  of  possible 
interpretations  that  are  permitted. 

4,3.1  Constraints  Omit  How  and  When 

Either  of  the  two  representations! 


says  thati 

the  activity  aj  is  dependent  on  "d" 
which  la  created  or  modified  by  the 
activity  a^. 

Each  representation  defines  a constraint  relationship  between  the  two 
boxes.  All  that  is  explicitly  stated  by  the  intermediate  arrow  for 
either  representation  is  expressed  as  follows  i some  activation  of  box  2 
requires  something  called  "d"  that  Is  produced  by  some  activation  of  box  1. 

Frequently,  diagrams  imply  strongly  that  two  or  more  boxes  must 
contend  for  the  contents  of  an  arrow.  The  meaning  of  the  boxes  and 
arrows  shown  in  Figure  4-7  is  that  something  produced  by  box  1 is  needed 
by  box  2 and  by  box  3.  It  may  be  that  an  activation  of  the  arrow's  "source" 
(box  1)  mu3t  precede  every  activation  of  its  "destination"  (box  2 or  box  3). 
It  may  be  that  one  activation  of  the  aource  is  sufficient  for  every  activation 
of  any  destination.  Without  additional  information,  the  boxes  and  arrows 
alone  permit  either  interpretation. 
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Flgur#  4-7.  Boxes  contending  for  content*  of  en  arrow 

4.3.2  Multiple  Input*.  Control*,  and  Outobt* 

The  basic  interpretation  of  the  box  ehown  below  is,  i„  order  to 
produce  any  subset  of  the  outputs  [01,  02,  031,  »ny  subset  of  the  entries 

[H,  12,  13.  Cl,  G2,  C3,  04]  ma^  be  required.  In  the  absence  of  further 
detailing  it  cannot  be  assumed  that, 

a.  any  output  can  be  produced  without  all  entries 
present,  or 

b'  any  output  requires  all  entries  for  its  production. 


Figure  4-8.  Illustration  of  Multiple  ICOM 


(1, 


The  partial  detailing  of  the  previous  box  (as  it  might  appear  in  an 
FEO  diagram)  indicates  that  13,  C2,  C3,  C4  are  not  required  for  producing 
01.  This  Illustrates  the  points  that! 

a.  some  form  of  further  detailing  will  specify  the  exact 
relationship  of  inputs  and  controls  to  outputs) 

I 

b.  until  that  detailing  is  provided,  limiting  assumption:! 
about  relationships  "inside"  each  box  should  not  be 
made) 

c.  reading  of  a diagram  should  concentrate  on  the  arrowa, 
which  are  explicit,  rather  than  on  box  contenta,  which 
are  only  implicit, 


Cl  C2  C3  C4 


Figure  4-9.  FEO  representing  detailing  of  multiple  ICOMs 


SECTION  S 

IDEF  FORMS  AND  PROCEDURES 


MECHANISM 


I DEF  KIT  CYCLE  FORMS  AND  PROCEDURES 


5. 1 jDEr  Teamwork  Dl»clplln» 

The  development  of  any  IDEF  model  (IDEFq,  IDEF^  end  IDEF^) 
le  a dynamic  procea*  which  require!  the  participation  of  more  than  one 
person.  Throughout  a project  the  draft  portions  of  a model  are  created 
by  authors  and  distributed  to  other  project  members  for  review.  These 
draft  portions  of  a model  are  called  Kits  and  may  contain  diagrams,  text, 
glossary  or  any  other  Information  the  author  feels  is  pertinent  to  the 
development  of  the  model. 

The  IDEF  teamwork  discipline  identifies  all  persons  interested  in 
the  review  of  a model  as  reviewers.  Reviewers  who  are  expected  to  make 
a written  critique  of  a Kit  are  called  commenters . Reviewers  who  receive 
a Kit  for  Information  only,  are  not  expected  to  make  written  comments  and 
are  called  readers. 

The  discipline  requires  that  each  person  expected  to  make  comment! 
about  a Kit  shall  make  them  in  writing  and  submit  them  to  the  author  of 
the  Kit.  The  author  responds  to  each  commenter  in  writing  on  the  same 

This  cycle  continue!,  encompaeaing  all  Kita  pertaining  to  a parti- 
cular model,  until  the  model  is  complete  and  recommended  for  publication. 

The  evolution  of  a model  is  recorded  by  disseminating  a model 
(with  most  recent  changes)  every  3 months  in  the  form  of  a Kit  which  is 
sent  to  readers  to  assist  them  in  maintaining  current  information  about  the 
model . 

The  end  effect  of  this  process  for  organised  teamwork  is  a high 
assurance  that  final  IDEF  models  are  valid  and  are  well  expressed.  The 
Kits  are  changed  to  reflect  corrections  and  valid  comments.  More  detail 
is  added  by  the  creation  of  more  diagrams,  text  and  glossary.  More 
comments  are  made)  more  changes  are  included.  The  final  model  represents 
the  agreement  of  the  aut’  r and  reviewers  on  a representation  of  the 
system  being  modeled  from  a given  viewpoint  and  for  a given  purpose. 


5.2  The  IDEF  Kit  Cycls 

In  creating  a document,  material*  written  or  gathered  by  an  author 


are  distributed  to  commentera  in  the  form  of  a Standard  Kit.  Commenters 
review  ths  material  and  write  comments  about  it.  The  commentera  return 
the  Kit  to  the  author  who  reacts  to  comments  and  may  use  the  comments 
to  revise  or  expand  the  material.  The  Kit  is  returned  to  the  commenter 
with  the  reactions  from  the  author.  This  is  known  as  a Kit  Cycle.  The 
steps  of  the  Kit  Cycle  are  as  follows! 

* The  author  assembles  the  material  to  be  reviewed  into 
a Standard  Kit1*1.  A cover  sheet  is  completed.  Copies 
of  the  kit  are  distributed  to  each  of  the  commenters  , 
and  to  the  author.  The  original  is  filed  for  reference. 

e Within  the  response  time  specified,  the  commenter  reads 
the  kit  and  wiites  comment*  directly  on  the  copy.  The 
kit  is  returned  to  the  author. 

e The  author  responds  in  writing  directly  on  each  com- 
menter'* copy.  The  author  may  agree  with  the  comment, 
noting  it  on  his  working  copy,  and  incorporating  it  into 
the  next  version  of  the  model.  If  there  is  disagreement, 
the  author  notes  the  disagreement  on  the  kit  and  return* 
it  to  the  commenter. 

e The  commenter  reads  the  author's  responses  and,  if 
satisfied,  files  the  kit,  (Commented  Kit*  are  always 
retained  by  the  Commenter. ) If  the  commenter  doe* 
not  agree  with  the  author's  responses,  a meeting  1* 
arranged  with  the  author  to  resolve  differences.  If 
this  cannot  be  done , a list  of  issues  is  taken  to 
appropriate  authority  for  decision. 

This  cycle  continue*  until  a document  is  created  which  represents  the 
careful  consideration  of  all  project  members.  In  addition,  a complete 
history  of  the  process  has  been  retained. 

The  results  of  this  Kit  Cycle  are  a document  to  which  author  and 
commenters  havo  contributed,  and,  if  necessary,  a list  of  issues  that 
require  management  action. 

Throughout  the  cycle,  a project  librarian  handles  copying,  distri- 
bution, filing,  and  transfer  of  kits  between  authors  and  commenters. 


’Types  of  IliEF  Kit*  are  explained  in  Section  5.3. 
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5.2.1  Peraonnel  Roles 


The  roles  and  functions  of  people  involved  arei 


Authors  (Modelers) 
Comtnenters  (Experts) 


Readers  (Experts) 


People  who  prepare  any  IDEF  model. 

People  knowledgeable  of  the  subject 
being  modeled  from  whom  authors 
may  have  obtained  information  by 
means  of  interviews , and  have 
enough, training  in  an  IDEF 
technique  to  offer  structured 
comments  in  writing,1*1 

People  knowledgeable  of  the  subject 
being  modeled  from  whom  authors 
may  have  obtained  information  by 
means  of  interviews!  and  review 
documents  for  information  but  are 
not  expected  to  make  written 
comments. 


Librarian 


A person  assigned  the  responsibility 
of  maintaining  a file  of  documents, 
making  copies,  distributing  kits 
and  keeping  records. 


A "role"  has  nothing  to  do  with  someone's  job  title,  and  the  same 
person  may  be  asked  to  perform  several  roles,  Thus,  each  individual's 
participation  is,  in  fact,  unique  and  depends  upon  the  kit  involved. 


5. 2. 1.1  Authors 

An  author  interviews  experts  and  creates  documents.  However, 
an  author  may  or  may  not  be  the  source  of  the  technical  content  of  a 
document.  An  author  may  serve  only  as  a technical  writer  or  scribe 
to  record  material  gathered  from  other  sources.  An  author  often  operates 
in  a role  which  is  largely  editorial!  identifying,  sorting  out,  and  organiz- 
ing the  presentation  of  knowledge  obtained  from  experts. 


•Comments  between  eommenter  and  author  are  considered  privileged 
Information.  Commented  kits  are  not  duplicated  for  distribution  to 
anyone  else  on  the  program.  The  library  does  not  retain  a file  of 
commented  copies. 


5. 2. 1.2  Commenter 


Commenters  read  material  produced  by  authors  and  verify  its 
technical  accuracy,  Commenters  are  responsible  for  finding  errors  and 
suggesting  improvements.  The  role  of  a commenter  is  the  key  to 
producing  high  quality  results.  The  commenter  determines  whether  the 
author  han  followed  the  IDEF  techniques  consistently)  whether  the 
viewpoint  and  purpose  have  been  adhered  to  and  whether  errors  or 
oversights  exist  which  should  be  brought  to  the  author's  attention. 

5.2.2  Guidelines  for  Authors  and  Commenters 


5.2.  i.l  Commenter  Guidelines 

No  set  pattern  of  questions  and  rules  can  be  adequate  for  comment- 
ing, since  subject  matter,  style,  and  technique  vary  so  widely.  However, 
guidelines  do  exist  for  improving  quality.  The  major  criteria  for  quality 
are i Will  the  document  communicate  well  to  lu  intended  audience?  Does 
it  accomplish  its  purpose?  Is  it  factually  correct  and  accurate,  given 
the  bounded  context?  Overall  guidelines  for  commenting  arei 

• Make  notea  brief,  thorough  and  specific.  As  long  as 
the  author  understands  that  niceties  are  dropped  for 
conciseness,  this  makes  for  easier  communication  and 
leas  clutter. 

e Use  the  0 notation  to  identify  comments.  To  write 
0-note,  check  the  next  number  off  the  NOTES  list 
number  the  note,  circle  the  number,  and  connect  the 
note  to  the  appropriate  part  with  a squiggle 
(See  Section  5,4  Standard  Diagram  Form) 

• Make  constructive  criticisms.  Try  to  suggest 
solutions,  not  just  make  negative  complaints. 

e Take  time  to  gather  overall  comments.  These 
may  be  placed  on  the  cover  or  on  a separate 
sheet.  (But  don't  gather  specific  points  onto 
this  sheet  when  they  belong  on  the  individual 
pages.)  Agenda  items  for  author /commenter 
meetings  may  be  summarised,  Make  agenda 
references  specific. 


The  length  of  time  spent  critiquing  depends  on  a variety  of  things i 
familiarity  with  what  is  being  described,  the  number  of  times  something 
has  been  reviewed,  the  experience  of  the  commenter  and  author,  etc, 

A kit  returned  to  an  author  with  no  comments  means  that  the  commenter 
is  in  total  agreement  with  the  author.  The  commenter  should  realise  that 
there  is  a shared  responsibility  with  the  author  for  the  quality  of  the 
work. 

5.2.2.2  Author /Commenter  Intarchanaes 

When  a commenter  returns  a kit,  the  author  responds  by  putting 
a or  "X"  by  each  <5 -note.  " Z1  means  tha  author  agrees  with  the 
commenter  and  will  incorporate  the  comment  into  the  next  version  of  the 
kit,  "X"  means  the  author  disagrees.  The  author  must  state  why  in 
writing  where  the  comment  appears.  After  the  author  has  responded  to 
all  comments,  the  kit  ia  returned  for  the  commenter  to  retain. 

Aftor  reading  the  author's  responses,  it  la  tha  commentate 
responsibility  to  identify  remaining  points  of  dieagraemant  and  to  request 
a meeting  with  the  author.  This  specific  list  of  issues  forms  the  agenda 
for  the  meeting. 

5.2.2.3  Meeting  Rules 

Until  comments  and  reactions  are  on  paper,  com  men  ter  e.  and  authors 
are  discouraged  from  conversing. 

When  a meeting  is  required,  the  procedure  is  as  follower 

1.  Each  meeting  should  be  limited  in  length. 

2.  Each  session  must  start  with  a specific  agenda  of 
topics  to  be  considered  and  must  stick  to  these 
topics. 

3.  Each  aesaion  should  terminats  when  the  partici- 
pants agree  that  the  level  of  productivity  has 
dropped  and  individual  efforts  would  be  more 
rewarding. 
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4.  Each  session  must  end  with  an  agreed  list  of  action 
items  which  may  Include  the  scheduling  of  follow-up 
sessions  with  specified  agendas. 

5.  In  each  session,  a "scribe"  should  be  designated  to 
take  minutes  and  note  actions,  decisions,  and  topics. 

6.  Serious  unresolved  differences  should  be  handled 
professionally,  by  documenting  both  sides  of  the 
picture. 

The  result  of  the  meeting  should  be  a written  resolution  of  the 
issues  or  a list  of  issues  to  be  settled  by  appropriate  managerial  decision. 
Resolution  can  take  the  form  of  more  study  by  any  of  the  participants. 


5.3  IDEP  Kits 

A Kit  is  a technical  document.  It  may  contain  diagrams,  text, 
glossaries,  decision  summaries,  background  information,  or  anything 
packaged  for  review  and  comment. 

An  appropriate  cover  sheet  distinguishes  the  material  as  a kit. 

The  cover  sheet  has  fields  for  author,  date,  project,  document  number, 
title,  status,  and  notes. 

There  are  two  types  of  IDEF  Kitsi 

e Standard  Kit  - All  kits  to  be  distributed  for  comment. 

It  is  considered  a "working  paper"  to 
assist  the  author  in  refining  his  total 
model  and  ia  limited  to  20  pages. 

e Summary  Kit  - Cental.- r;  the  latest  version  of  a model. 

It  is  sen;  for  information  only  and  is 
designed  to  aid  [rTmaintainihg  current 
information  about  the  total  model  while 
portions  of  the  model  are  being  pro- 
cessed through  the  Kit  Cycle. 
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Standard  Kita  contain  portions  of  a model  and  are  submitted 
frequently  as  work  progresses.  Standard  Kits  are  submitted  through 
the  IDEF  Kit  Cycle  for  review  and  are  the  type  referred  to  in  this  manual. 

Summary  Kita  are  aubmitted  every  three  months.  These  kite 
contain  the  latest  version  of  the  model.  Recipients  of  Summary  Kita  are 
not  expected  to  make  comments  on  them  although  they  may  choose  to  do  so. 
Summary  Kits  are  kept  by  the  recipients  for  their  files.  A description  of 
Summary  Kita  is  found  in  the  "ICAM  Library  User's  Guide." 

5-3.1  Completing  a Cover  Sheet  for  « Standard  Kit 

Complete  one  cover  sheet  for  each  kit  submitted.  (No  reproductions) . 
Fill  In  the  following  fields  on  the  Cover  Sheet  (Figure  5-2). 


1.  MODEL /DOCUMENT  DESCRIPTION  I 

Title  - Should  be  descriptive  of  the  kit 
Life  Cycle  Step  - "AS  IS"  or  "TO  BE" 

IDEF  Methr  ' -0,  1 or  2 
System  - onym  for  System  or  Subsystem 
Distribute  . Type  - Specify  if  other  than  Standard 
Kit  Diatribution* 

2.  PROJECT  INFORMATION! 

Author  - Name  of  person  submitting  kit** 

Date  - Date  aent  to  Library 

Company  - Name  of  company  submitting  kit 

A.F.  Project  No.  - 

Task  No.  - 

3.  KIT  INFORMATION! 

Check  Standard  Kit,  indicate  document  number  assigned 
by  Library  if  this  is  a revision  to  a Standard  Kit 

4.  REVIEW  CYCLE) 

To  be  signed  and  dated  after  review  by  commenter 
and  author. 


♦Types  of  Distribution  available  are  discussed  in  Volume  XI  of  this  report. 

**In  cases  where  a Standard  Kit  is  submitted  as  s group  effort  (l.e..  task 
team,  committee,  or  co-authors)  one  individual  from  the  group  assumes 
responsibilities  as  "author," 


aBOOBBBDOIggHBlE 


5.  NODE  INDEX/CONTENTSi 

Node  number,  title  and  C-number  of  each  page 
of  the  document  (including  the  cover  sheet) 

CONTENTS  SHEET,  Figure  5-4  (if  needed)  le 
always  Page  2. 

6.  COMMENTS/SPECIAL  INSTRUCTIONS) 

Any  other  information  for  the  reviewers.  This 
can  also  be  used  for  special  instructions  to  the 
library  about  the  handling  of  the  document.  The 
library  also  uses  this  field  for  special 
instructions  to  receiver  of  kits. 

5.3.2  How  to  Prepare  a Standard  Kit 

To  avoid  oversights,  review  the  kit  as  if  that  were  the  only  infor- 
mation available.  Catch  any  typographical  errors.  Add  points  of  clari- 
fication that  come  to  mind  as  brief  notes  on  the  kit  itself.  Glossary 
definitions  for  terms  that  appear  in  the  kit  should  always  be  appended 
as  support  material. 

Gather  helpful  materials  and  append  these  for  the  commenter's 
benefit.  Never  use  this  supplemental  material  to  convey  information  which 
should  properly  be  conveyed  by  the  diagram  itself.  Whenever  possible,  use 
the  most  natural  means  of  communication  - diagrams  - to  show  details 
that  are  important  for  the  reader  in  understanding  the  concepts.  Combine 
all  material  with  a completed  Cover  Sheet  and  Node  Index /Contents  Sheet 
and  submit  to  the  Library. 

5.4  Standard  Diagram  Form 

The  Diagram  Form  (Figure  5-5)  has  minimum  structure  and 
constraints.  The  sheet  rupports  only  the  functions  important  to  the 
discipline  of  structured  analysis.  They  are) 

# Establishment  of  context} 

e Cross-referencing  between  pieces  of  paper; 

• Notes  about  the  content  of  each  sheet. 


I DCF  KIT  COHTEMTS  FORM 


Figure  5-4.  IOEF  Node  Index /Contents  Sheet 


The  diagram  form  Is  a single  standard  size  for  ease  of  filing  and  copying. 
The  form  Is  divided  into  three  major  sections! 

• Working  Information  (top) 

• Message  Field  (center) 

• Identification  Fields  (bottom) 

The  form  is  designed  so  that  the  working  information  at  the  top  of  the 
form  may  be  cut  off  when  a final  "approved  for  publication"  veraion  is 
completed.  The  diagram  form  should  be  used  for  everything  written. 

5.4.1  Working  Information 

The  "Author/Date/Project"  Field 

This  tells  who  originally  created  the  diagram)  the  date  that  it  was 
first  drawn,  and  the  project  title  under  which  it  was  created.  The  "date" 
field  may  contain  additional  dates,  written  below  the  original  date.  These 
dates  represent  revisions  to  the  original  sheet.  If  a sheet  is  re-released 
without  any  change,  then  no  revision  date  is  added. 

The  "Notes"  Field 

This  provides  a check-off  for  (n)  notes  written  on  the  diagram 
sheet.  As  comments  are  made  on  a page,  the  notes  are  successively 
crossed  out.  The  crossing  out  provides  a quick  chock  for  the  number  of 
comments,  while  the  circled  number  provides  a unique  reference  to  the 
specific  comment. 

The  "Status"  Field 

The  status  classifications  provide  a ranking  of  approval.  They 

are ! 

WORKING  The  diagram  is  a major  change,  regard 

less  of  the  previous  status.  New  dia- 
grams are,  of  course,  working  copy. 
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The  diagram  la  a minor  change  from  the 
previous  diagram,  and  has  reached  some 
agreed-upon  level  of  acceptance  by  a 
set  of  readers.  Draft  diagrams  are 
those  proposed  by  a task  leader,  but 
not  yet  accepted  by  a review  meeting 
of  the  technical  committee  or  coalition. 

Both  this  diagram  and  its  supporting 
text  have  been  reviewed  and  approved 
by  a masting  of  the  technical  committee 
or  coalition,  and  this  diagram  is  not 
expected  to  change, 

This  page  may  be  forwarded  as  la 
for  final  printing  and  publication^ 

The  11  Reader /Date"  Field 

This  area  is  where  a commenter  should  initial  and  date  each  form. 

The  "Context11  Field 

This  indicates  the  context  in  which  the  diagram  form  is  to  be 
Interpreted.  The  context  sketch  always  is  at  the  next  higher  level  from 
the  current  diagram.  The  current  diagram  is  shown  as  a box  in  the 
sketch,  to  highlight  it)  all  other  parts  of  the  higher  level  are  drawn  as 
ovals.  Arrows  are  omitted.  The  node  number  of  the  higher  level  diagram 
is  written  in  the  lower  left  of  the  Context  field. 


DRAFT 


RECOMMENDED 


PUBLICATION 


Node  number 
of  context 


Figure  5-6.  Illustration  of  Context  Field 

The  Context  field  of  a context  diagram  (A-0)  is  "NONE."  The  Context 
field  of  a top  level  diagram  (AO)  is  "TOP." 


. i 
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The  "Used  At"  Field 


This  Is  a list  of  diagrams,  other  than  the  Immediate  context, 
which  use  this  sheet  in  some  way. 

5.4.2  The  "Message11  Field 

The  Message  field  contains  the  primary  message  to  be  conveyed. 
The  field  is  normally  used  for  diagramming.  However,  the  field  can  be 
used  for  any  purpose)  glossary,  checklists,  notes,  akotches,  etc.  The 
author  should  use  no  paper  other  than  diagram  forms. 

5.4.3  The  ''Title11  Field 

The  Title  field  contains  the  name  of  the  material  presented  on  the 
Diagram  Form.  If  the  Message  field  contains  a diagram,  then  the  contents 
of  the  Title  field  must  precisely  match  the  name  written  in  the  parent  box. 

5.4.4  The  "Number11  Field 

This  field  contains  all  numbers  by  which  this  sheet  may  be 
referenced. 

C- Number 

The  C-number  is  composed  of  two  or  three  letters  of  the  author's 
initials  followed  by  a number  sequentially  assigned  by  the  author.  This 
C-number  is  placed  in  the  lower  left  corner  of  the  Number  field  and  is 
the  primary  means  of  reference  to  a sheet.  Every  diagram  form  used  by 
an  author  receives  a unique  C-number.  When  a model  is  published,  the 
C-number  may  be  replaced  by  a standard  sequential  page  number  (e.g. , 
"pg.  17"). 

Pago  Number 

A kit  page  number  ia  written  by  the  librarian  at  the  right  hand 
side  of  the  Number  field.  This  ia  composed  of  the  document  number 
followed  by  a number  identifying  the  sheet  within  the  document. 
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Each  person  participating  in  a project  should  maintain  files  of  the 
documents  received.  The  librarian  maintains  the  master  and  refnrence 
files  for  each  kit  submitted  during  the  course  of  a project.  A complete 
explanation  of  library  files  is  given  in  the  "ICAM  Program  Library  Main- 
tenance Procedures, n Volume  XX  of  this  report. 

Variations  in  the  filing  process  may  occur  baaed  on  individual  pre- 
ferences but  it  is  recommended  that  these  files  be  maintained) 

s Standard  Kit  Files,  maintained  by  authors  and 
commentera 

e Summary  Kit,  maintained  by  authors,  commenters, 
and  readers 

e Working  Files,  maintained  by  authors 

5. 5. 1 Standard  Kit  File 

This  file  contains  the  Standard  Kits  issued  or  received.  A record 
of  kits  filed  should  be  maintained  and  should  include  any  information  that 
allows  convenient  access  to  the  contents  of  the  kit. 

5.5.2  Summary  Kit  Flit 

This  file  contains  the  Summary  Kits  issues  or  received.  A record 
of  these  kita  should  also  be  maintained. 

5.5.3  Working  File 

This  file  contains  all  documentation  that  has  not  been  submitted  in 
a kit.  Work  in  progress  and  notes  should  be  kept  in  this  file. 


5. 6 The  IDEE  Modal  Walk-Through  Procedure 

In  addition  to  the  Kit  Cycle,  a Walk-Through  Procedure  has  been 
developed,  This  procedure  may  be  used  when  the  participants  in  building 
a model  can  be  assembled  for  commenting. 

1.  Present  the  model  to  be  analysed  by  using  ita  node  index. 
This  is  the  model's  table  of  contents  and  gives  the 
reviewer  a quick  overview  of  what  is  to  come. 

2.  Present  a Cloasary  of  Terms.  This  will  allow  each  reviewer 
to  replace  personal  meanings  of  words  with  those  that 

the  presenting  team  has  chosen.  The  meanings  should 
not  be  questioned  at  this  point.  A change  in  meaning 
now  would  require  many  changes  in  the  diagrams. 

3.  Present  each  diagram  for  review. 

The  diagram  walk-through  proceaa  is  an  orderly,  step-by-step  process 
where  questions  esn  be  asked  that  may  identify  potential  weaknesses  in 
the  diagram.  Six  stops  of  a structured  walk-through  follow  below. 

Diagram  corrections  may  be  proposed  at  any  atep.  These 
corrections  may  be  noted  for  execution  at  a later  date  or  adopted 
immediately. 

Step  li  SCAN  THE  DIAGRAM 

This  step  allows  the  reader  to  obtain  general  impreasiona  about 
the  content  of  the  diagram.  Typically,  the  reader  will  have  reviewed 
the  parent  diagram  which  depicted  the  current  diagram  as  one  of  ita 
boxes.  The  reader  is  now  examining  how  the  author  decomposed  that 
box. 


CRITERIA  FOR  ACCEPTANCE i 

1.  The  decomposition  ia  useful  for  its  purpose  and 
complete  within  the  context  of  its  parent  box. 

All  lower  level  functions  or  data  can  clearly  be 
categorized  under  each  of  ita  boxes. 

2.  The  diagram  reflects,  in  the  reviewer's  opinion, 
a relevai  ' point  of  view  baaed  on  the  purpose  of 
the  model. 
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3. 


In  the  opinion  of  the  reviewer,  there  ie  enough  new 
information  provided  to  extend  underatending  of  the 
parent  box.  There  ia  not  ao  much  detail  that  the 
diagram  appears  complex  and  hard  to  read. 

Unless  a problem  is  rather  obvious,  criticism  may  be  delayed  until 
Step  3 below,  However,  first  impressions  should  not  be  lost.  They  might 
be  put  on  a blackboard  or  flip  chart  pad  until  resolved. 

Step  2t  LOOK  AT  THE  PARENT 

Once  the  reader  understands  the  current  diagram's  decomposition, 
the  parent  diagram  should  be  reviewed  to  insure  compatibility. 

CRITERIA  FOR  ACCEPTANCE i 

1.  The  decomposition  covers  all  of  the  points  the 
reviewer  anticipated  wheit  reading  the  parent 
diagram . 

2.  Now  that  the  decomposition  of  this  portion  of  the 
parent  diagram  is  revealed,  the  detail  which  the 
reviewer  envisioned  for  this  box  should  still  seem 
correct.  If  not,  note  the  missing  detail. 

It  might  be  important  at  this  step  to  return  to  the  parent  diagram 
briefly  and  add  new  @ - notes  or  embellish  existing  ones,  based  upon 
the  added  insight  gained  from  this  look  at  the  decomposition. 

Step  3)  CONNECT  THE  PARENT  BOX  AND  THE  DETAIL  DIAGRAM 

This  step  tests  the  arrow  interface  connections  from  the  parent  to 

child. 


CRITERIA  FOR  ACCEPTANCE) 

1.  There  are  no  missing  or  extra  interface  arrows. 

2.  Interface  arrows  are  labeled  with  proper  ICOM  codes. 

Child  arrow  labels  are  the  seme  or  an  elaboration 
of  its  parent's  matching  arrow.  Labels  convey  the 
correct  and  complete  arrow  contenta. 


3. 


4. 


Examination  of  the  connecting  arrows  reveal  no  problems 
in  the  parent  diagram.  (An  added  interface  may  create 
a misunderstanding  of  the  message  conveyed  by  the 
parent. ) 

A clockwise  tour  of  the  four  edges  of  the  parent  box*  checking 
each  arrow,  will  provide  a methodical  way  to  check  matching  of  ICOM  codes 
with  parent  arrows. 

Step  4 1 EXAMINE  INTERNAL  ARROW  PATTERN 


The  pattern  of  boxes  and  arrows  constitute  the  primary  expression 
of  the  model  being  created. 

Each  box  will  be  examined  in  node  number  order,  and  each  arrow 
followed  in  ICOM  order  for  each  box.  When  this  process  is  complete,  the 
reviewers  should  be  led  through  the  diagram  to  explore  the  consequences 
of  situations  with  which  reviewers  are  familiar  and  to  teat  the  diagram's 
capability  to  simulate  the  relationships  known  to  exist. 

CRITERIA  FOR  ACCEPTANCEi 

1.  The  diagram  does  not  look  cluttered.  The  number  of 
arrow  crossings  and  bends  is  minimised. 

2.  The  boxes  should  be  balanced  with  regard  to  detail. 

There  should  be  an  equal  amount  of  detail  within 
each  box.  However,  compromises  on  this  criterion 
are  acceptable  for  the  sake  of  clarity. 

3.  The  diagram  should  be  consistent  with  the  reviewer's 
experience  and  knowledge  of  the  subject  matter. 

Feedback  and  error  conditions  should  be  shown  as 
the  reviewer  expects. 

Step  5 1 READ  THE  SUPPORTIVE  DOCUMENTATION 

This  step  examines  the  points  that  the  author  highlights  in  the 
text,  glossary  and  FEOs. 

CRITERIA  FOR  ACCEPTANCEi 

1.  The  text  confirms  the  interpretation  obtained  from 
examining  the  diagram  itself, 

2.  Normal-paths,  feedback,  error-handling,  and  other 
features  suggested  by  the  text  are  found  in  the 
diagram  or  found  in  an  FEO  (For  Exposition  Only) 
diagram. 
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3.  Significant  diagram  features  uncovered  during  Steps  1-4 
are  found  in  the  text,  glossary  or  FEO. 

4.  References  to  the  diagram  are  detailed  enough  to 
connect  text,  glossary  or  FEO  to  specific  parts  of  a 
diagram. 

Step  6 1 SET  THE  STATUS  OF  THE  DIAGRAM 


1.  Recommended  as  it  stands. 

2.  Recommended  as  modified. 

3.  Draft i Too  many  changes  made,  a redraw  is 

necessary,  and  future  review  is  required, 

4.  Not  Accepted)  A complete  re-analysis  is 

required . 


SECTION  6 

AUTHOR'S  GUIDE  TO  CREATING 
IDEFq  diagrams 


MECHANISM 


AUTHOR'S  GUIDE  TO  CREATING  IDEF0  DIAGRAMS 

When  creating  any  IDEFq  diagram)  the  requirement#  to  be  aatiafied 
are  thati 

a.  Its  purpose  and  viewpoint  must  match  the 
stated  purpose  and  viewpoint  of  the  overall 
model  | 

b . its  boundary  arrows  must  correspond  to  those  of  Its 
parent  diagram  | 

c.  its  content  must  be  exactly  everything  in  its  parent 
box. 


6.1  Basic  Steps  of  Authoring 

The  step-by-step  discipline  of  authoring  makes  it  possible  to 
create  diagrams  that  form  useful  and  coherent  models.  The  discipline 
to  follow  is  i 

a.  Bound  the  subject  matter  more  precisely  than  the 
title  of  the  function  box  suggests.  This  ia  done 
with  a list  of  data  (objects  or  Information)  acted 
on  or  processed  by  the  function. 

b.  Study  the  bounded  set  of  subject  matter  and  form 
possible  aubfunctions  of  the  total  function. 

c . Look  for  natural  patterns  of  connection  of  those 

sub  functions.  ” 

d.  Split  and  combine  aubfunctions  to  make  other  boxes. 

e.  Draw  a final  version  of  the  diagram  with  careful 
attention  to  layout  and  clarity. 


6.1.1  Selecting  s Context.  Viewpoint,  snd  Purpose 

Before  beginning  any  model,  it  is  important  to  determine  the 
model's  otiontaticm.  This  includes  the  context,  viewpoint,  snd  purpose. 


The  context  establishes  the  subject  of  the  model  as  part  of  a larger 
whole.  It  creaks  a boundary  with  the  environment  by  describing  external 
interfaces . 

The  viewpoint  determines  what  can  be  "seen"  within  the  context, 
and  from  what  "slant."  It  states  the  author's  position  as  an  observer  of 
or  participant  in  the  system  for  the  benefit  of  an  audience.  Depending 
on  the  audience  (management,  technical,  customer,  etc.),  different 
viewpoints  may  be  adopted  that  emphasize  different  aspects  of  the 
subject. 

Only  one  viewpoint  per  modal. 

One  model  can  serve  to  reflect  only  one  purpose  and  can  follow 
only  one  viewpoint. 

The  purpose  establishes  the  intent  of  the  model  or  the  goal  of 
communication  that  it  serves.  Purpose  embodies  the  reason  why  the 
model  is  created  (functional  specification,  implementation  design,  customer 
operations,  etc.). 

These  concepts  guide  and  conetrain  the  creation  of  a model.  While 
they  may  bo  refined  as  authoring  proceeds,  they  must  be  consistent  through- 
out a model  if  its  orientation  is  to  remain  clear  and  undistorted, 


Cryatallze  your  purpose. 

Without  conscious  effort,  in  the  process  of  detailing,  the 
author  can  stray  from  the  original  purpose, 

The  starting  point  for  ovary  analysis  1b  to  bound  the  context. 
Decide  what  the  focus  is  before  the  top-most  box  is  created.  Beware 
of  drifting  out  of  this  carefully-selected  star  Ling  domain. 
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Every  step  should  be  checked  against  the  starting  purpose. 
Things  that  don't  fit  may  be  noted  for  later  modeling  of  the  relevant 
views . 

Clarity  is  derived  from  the  rigors  of  detailing.  Knowing  how 
far  to  go,  when  to  stop,  when  to  change  gears,  and  how  the  pieces 
fit  together  will  always  depend  on  the  purpose  for  whi  a a model  is 
created, 


6.1.2  Cresting  the  Context  Dlsgram 

To  start  a model,  create  the  A-0  diagram.  Draw  a single  box  con- 
taining the  name  of  the  function  which  encompasses  the  entire  scope  of  the 
system  being  described.  Use  arrows  entering  and  leaving  the  box  to 
represent  the  data  interfaces  of  the  system  to  its  environment.  This 
single-box  diagram  bounds  the  context  for  the  entile  model  and  forms 
the  basis  for  further  decomposition  efforts. 

Some  authors  find  it  easier  to  sketch  the  AO  and  then  draw 
the  single  box  and  interface  arrows  shown  at  level  A-0.  It  may  be 
necessary  to  switch  diagramming  efforts  back  and  forth  between 
A-0  and  AO  several  times  to  obtain  a good  start  for  the  decomposition. 

If  the  A-0  diagram  has  begun  at  too  low  a level  of  detail,  make 
the  A-0  box  the  basis  of  a new  level  AO  diagrrm.  Move  up  one  level  to 
a new  A-0,  Repeat  this  process  until  an  A-J  is  reached  whicli  has 
sufficient  scope  to  cover  all  aspects  of  the  system,  (Sometimes  such  a 
higher  level  will  broaden  rather  than  clarify  the  chosen  viewpoint.  If 
so,  make  an  A-l  multi-box  context  diagram  and  keep  the  AO  diagram  to 
the  original  intent.) 


6.1.3  Creating  the  Top-most  Diagram 

All  system  functions  lie  within  the  single  box  shown  on  the  A-0 
diagram.  The  diagram  bounds  the  context  of  the  system.  The  AO  diagram 
decomposes  the  A-0  diagram  into  its  three  to  six  major  subfunctions. 

The  real  "top"  of  the  model  is  the  AO  diagram.  It  is  the  first  and 
most  Important  expression  of  the  model's  viewpoint.  Its  structure  clearly 
shown  what  the  A-0  diagram  tried  to  uay.  The  terms  and  structure  of  AO 
also  bound  every  subsequent  level  because  it  is  a complete  description  of 
the  chosen  subjept.  Lower  levels  delineate  each  of  the  AO  functions 
(boxes) . If  the  purpose  of  the  model  is  to  be  achieved,  this  chain  of 
detailing  must  be  carefully  followed  at  each  step.  Beginning  at  the  top 
is  the  challenge  of  authoring.  It  forces  the  author  to  maintain  a level  of 
abstraction,  keep  an  even  model  depth,  and  relegate  details  to  a lower 
level . 

6.1.4  Creating  Subsequent  Diagrams 

To  form  the  structure  of  diagrams,  decompose  each  box  on  the  AO 
diagram  into  its  major  part.  Form  a new  diagram  which  covers  the  same 
topic  as  its  parent  box  but  in  more  detail. 

To  decompose  each  box  into  3-6  boxes,  obtain  the  needed  additional 
facts.  Create  a first-draft  diagram  by  listing  all  data  items  and  activities 
contained  in  the  box  being  decomposed.  Take  care  that  these  lists  cover 
the  entire  topic  of  the  parent  box  so  that  no  portion  is  lost  in  the  decom- 
position. Draw  boxes  which  are  based  on  these  lists  and  draw  interface 
arrows  between  these  boxes. 

To  derive  the  clearest  possible  diagram,  modify  or  re-draw  the 
diagram  several  times  until  satisfied.  Split  (break  up  a box  into  two  or 
more  parts)  and  cluster  (combine  two  or  more  parts  into  a single  box) 
until  satisfied. 

Generate  portions  of  more  detailed-level  diagrams  to  explore  points 
which  need  clarification.  Create  several  (3  or  4)  diagrams  as  a set, 
rather  than  one  diagram  at  a time. 
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6.1.5  Creating  Supporting  Material 

Eventually,  each  diagram  will  be  accompanied  by  a page  of  narrative 
text,  glossary  and,  perhaps,  FEOs.  The  text  associated  with  the  A-0  diagram 
should  complete  the  model's  orientation  and  is  written  when  the  A-0  diagram  is 
created.  The  text  complements  the  context  (expressed  in  A-0  itself)  by 
expanding  upon  the  stated  viewpoint  and  purpose  of  the  model . 

Text  for  every  other  diagram  (Including  AO)  is  quite  different. 

It  tells  a brief,  concise  story.  It  does  not  duplicate  what  the  diagram 
already  says,  but  weaves  through  its  patterns.  At  every  level,  this 
captures  the  viewpoint  in  a way  that  furthers  the  purpose. 

The  glossary  explains  the  definitions  the  author  gives  to  functions 
and  data  in  a diagram.  These  definitions  are  important  because  the 
terminology  used  in  the  model  may  have  a completely  different  meaning  in 
one  company  from  the  meaning  in  another  company. 

FEO's  (For  Exposition  Only)  are  diagrams  that  highlight  a particu- 
larly interesting  or  subtle  aspect  of  a diagram.  They  are  not  bound  by 
IDEF  syntax  and  may  contain  partial  arrow  structure,  notes,  etc.  to 
emphasize  their  point. 

6.1.6  Selecting  a Box  to  Dscompota 


Given  a complete  parent  diagram,  "firm  up"  the  higher  levels  before 
overcommitting  to  details.  That  is,  given  AO,  emphasize  work  on  Al,  A2 
A3.  Decomposing  Al  into  All,  Alll,  should  be  done  lster,  This  avoids 
potential  rework  should  changes  be  made  to  higher  level  diagrams. 

Keeping  an  even  depth  is  not  a strict  rule.  The  amount  of  depth 
at  any  time  depends  on  whether  more  depth  would  capture  meaning  better 
than  one  diagram.  Don't  put  off  doing  a lower  level  diagram,  e.g.  Alll, 
sketch  while  the  ideas  are  fresh.  The  important  thing  is  to  treat  all  such 
forays  as  sketches  until  the  "horizontal"  even  level  is  confirmed.  Be 
ready  to  rework  the  lower  level  material  if  it  conflicts  with  higher  level, 
e.g,,  Al,  A2,  A3,  ( etc , ) , 
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Two  guidelines  are  helpful  In  deciding  which  box  to  decompose: 

1.  Start  with  the  "hard  part"  — the  part  that  ia  least 
familiar  or  is  least  clear. 

2.  Select  the  box  whose  decomposition  will  give  the  most 
information  about  other  boxes. 

The  simpler  topics  can  be  more  easily  decomposed  later,  with  less  risk  of 
error  or  oversight,  and  can  be  easily  manipulated  to  fit  the  decomposition 
of  the  more  complex  issues. 

6.1.7  Author  Activities 


6. 1.7.1  Dsts  Gathering  Phase 

Read  Background 

The  author  gathers  information  about  the  subject  matter  by  read- 
ing source  information. 

Interview 

The  author  personally  interviews  an  expert  on  the  subject  matter. 
This  Interview  is  not  used  for  multi-pernon  planning  or  review  meetings. 

Think 

Digest  the  information  obtained  from  reading  and  interviews  before 
actual  diagramming  begins. 

Pick  Box 

Decide  which  box  is  the  appropriate  one  to  detail  based  on  informa- 
tion obtained. 

6. 1.7. 2 Structuring  Phase 

Draw 

This  encompasses  the  actual  creative  procesi  of  generating  a dia- 
gram. It  Is  not  limited  only  to  drawing  boxes  and  arrows,  It  also  Includes 
the  listing  of  random  data  elements,  making  sketches,  etc.  , which  precede 
drawing  boxes  and  arrows. 


Redraw 


This  covers  the  digestive  stage  of  diagramming  and  corresponds  to 
editing  and  rework  of  verbal  text.  The  activity  here  ia  concerned  not 
with  creating,  but  with  graphical  editing  and  rearranging  for  clarity. 

Fix  Maater 

This  applies  to  the  correction  of  master  drawings  to  incorporate 
improvements.  It  la  primarily  a mechanical  operation  which  reaulta  from 
the  fact  that  masters  are  set  aside  while  changes  are  made  on  copies. 

6. 1.7. 3 Presentation  Phase 

Write  and  Edit  Text 

Text  accompanying  any  diagram  should  be  precise.  Editing  will 
often  alleviate  unnecessary  detail  and  redundancy. 

Assemble 

Assemble  any  material,  diagrams,  node  trees,  glossaries,  text, 
etc.  relevant  to  the  subject.  Include  a completed  Cover  Sheet. 

6. 1.7.4  Interaction  Phsie 

React 

This  refers  to  the  author  reacting  to  comments.  It  is  a combination 
of  reading  and  annotating  reactions  to  the  comment 3. 

Talk 

This  represents  time  spent  when  an  author  and  commenter  actually 
get  together  and  talk  about  author  reactions  to  the  comments. 

Group  Meetings 

This  is  the  time  spent  in  group  meetings  reviewing  progress  or 
brainstorming  next  steps.  The  minutes  of  the  group  meetings  will  identify 
the  subject  matter  under  discussion. 
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6.2 


Drawing  an  IDEFQ  Diagram 

Diagram  creation  is  the  most  subjective  and  creative  activity  of  the 
modeling  process.  It  is  open  to  wide  variations  between  individual  authors. 
No  one  set  of  steps  will  work  equally  well  for  all  authors.  The  steps 
presented  here  are  a proven  sequence  and  are  designed  to  assist  a new 
author  in  drawing  IDEFq  diagrams. 

a.  Create  a relevant,  but  not  yet  structured  list  of  data. 

List  items  within  the  context  of  the  parent  box 

that  first  come  to  mind.  Croup  items,  if  possible,  to 
show  similarities. 

b.  Name  functions  that  act  on  the  listed  data  and  draw 
boxes  around  the  names. 

c . Sketch  appropriate  arrows . As  each  box  is  drawn , 
leave  arrow  "stubs"  to  make  the  box  more  meaningful, 

Make  complete  connections  as  it  becomes  obvious  what 
the  diagram  is  saying. 

d.  Draft  a layout  that  presents  the  clearest  box  and 
arrow  arrangement,  Bundle  arrows  together  if  the 
structure  is  too  detailed.  Leave  only  the  essential 
elements,  and  modify  diagram  as  necessary. 

e.  Create  text,  glossary  and  FEO  (For  Exposition  Only) 
diagrams,  if  necessary,  to  highlight  aspects  which 
are  important.  Propose  changes,  if  needed,  in  the 
parent  diagram. 


6.2.1  Generating  Function  Boxes 

Function  boxes  are  generated  uaing  the  major  subfunctions  of  the 
parent.  As  subfunction  names  are  written,  draw  boxes  around  them  to 
form  the  start  of  an  actual  diagram.  At  this  stage  the  number  of  boxes, 
is  immaterial.  They  can  be  modified  by  clustering  and  splitting. 


Clustering  will  group  two  or  more  boxes  to  form  a single  box.  Its 
goal  is  to  cluster  related  functions  into  a single,  more  general  function. 

It  eliminates  premature  detail  which  obscures  the  message  to  be  conveyed 
at  this  level, 

Splitting  will  break  a single  box  into  two  or  more  parts,  It  is  the 
inverse  of  clustering.  Its  goal  is  to  provide  more  detail  to  present  suffi- 
cient understanding  of  the  subject  being  decomposed. 

Review  the  resulting  set  of  function  boxes.  Look  for  good  balance 
between  the  factors  chosen.  See  if  the  names  can  be  made  more  specific. 
Use  special  terms  and  abbreviations  only  when  needed  to  promote  communi- 
cation with  the  intended  audience  and  only  at  the  detailed  diagram  level*. 
Do  not  use  them  at  the  highest  (A-0  and  AO)  levels.  Carefully  define 
special  terms  in  the  glossary. 

In  all  cases,  make  the  function  box  names  verb  phrases.  Whenever 
the  phrase  can  be  interpreted  as  either  a verb  or  a noun,  use  the  notation 
11  (v)"  to  signify  the  intended  verb  usage. 

Boxes 


1.  In  moat  cases,  layout  boxes  diagonally  from  upper 
left  to  lower  right.  While  any  layout  which  makea 
clear  the  author's  intent  is  acceptable,  vertical 

or  horizontal  format*  tend  to  crowd  arrowu  and  hinder 
good  structured  analysis  style. 

2.  Boxes  placed  in  the  upper  left  "dominate"  boxea 
placed  lower  and  to  the  right  through  the  control 
arrows  that  link  them.  This  standard  style  makes 
it  easier  for  readera  to  understand  your  meaning. 

3.  Number  each  box  in  its  lower  right  corner.  Assign 

the  box  numbers  on  a diagram  from  left  to  right  and  from 
top  to  bottom.  This  defines' the  node  number  for  each 
box.  The  leading  digits  of  the  box's  complete  node 
number  are  the  same  as  this  diagram's  node  number. 

The  last  digit  of  the  node  number  is  this  box  number. 

If  the  box  in  Figure  6-1  is  in  diagram  A4,  the 
complete  node  number  for  this  box  is  A42, 
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TITLE 

2 


Figure  6-1.  Box  Number 

4.  On  working  or  draft  copies,  write  the  author 
C-number  below  the  lower  right  corner  of  any 
box  that  is  decomposed. 

5.  No  diagram  may  contain  more  than  six  boxes. 

6.1.2  Creating  Interface  Arrows 

Sketch  data  interface  arrows  on  each  individual  box.  Connect  ends 
of  arrows  to  show  which  outputs  supply  which  inputs  and  controls. 

Recall  that  input  data  are  transformed  by  the  function  to  produce 
the  output.  If  an  arrow  contains  both  input  and  control  data,  show  it  as 
a control.  If  it  Is  uncertain  whether  an  arrow  is  a control  or  an  input, 
make  it  a control.  It  it  is  unclear  whether  or  not  a particular  piece  of 
data  is  needed  at  all,  luave  It  out. 

Output  arrows  show  the  results  of  possible  activations  of  the 
function.  The  syntax  for  output  arrows  does  not  indicate  which  patterns 
of  output  arrows  may  occur  under  which  circumstances.  If  the  sequence 
is  of  particular  interest,  draw  a FEQ  illustrating  the  pattern.  Do  not 
worry  about  sequence.  Just  make  sure  that  all  important  coses  are 
allowed  by  the  diagram. 

Bundle  groups  of  related  arrows  whenever  possible.  The  most 
common  mistake  when  creating  arrows  is  to  make  the  arrow  structure  or 
the  arrow  labels  too  detailed.  The  level  of  detail  of  arrows  must  match 
the  level  of  detail  of  boxes.  At  high  levels,  both  box  names  and  arrow 
labels  will  be  general, 

As  a final  check,  compare  all  arrows  to  the  data  list  to  insure  that 
each  correct  data  item  appears,  Elements  that  do  not  appear  are  either 
incorrect  for  this  level  of  detail  or  were  overlooked  when  creating  the  arrows. 
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Think  control  and  constraint.  not  flow 

A basic  rule  for  layout  of  the  arrow  structure  is  "constrain , 
don't  sequence."  lh&t  is,  make  the  diagram  structure  show  relation- 
chips  that  must  be  true  no  matter  which  sequence  is  followed, 

Even  though  something  must  progress  from  stage  to  stage  to 
reach  some  desired  end  result,  try  to  express  the  constraints  that  must 
be  satisfied  or  the  Invariant  properties  that  must  be  true  rather  than 
some  one  specific  sequence  of  steps  that  will  yield  that  result. 

The  reason  is  that  all  boxes  may  be  active  simultaneously.  Thus, 
sequence  has  no  meaning. 

It  is  always  more  powerful  to  constrain  than  to  sequence.  Where- 
ever  possible,  diagrams  should  be  created  that  say  the  right  thing 
regardless  of  what  steps  are  taken  first.  Clearly,  this  is  better  than 
restricting  to  only  one  of  the  possible  sequences. 

Often,  It  is  easiest  at  first  to  think  of  submodule  actions  in  a 
particular  sequence  to  get  unstuck  and  get  something  on  paper.  This 
may  be  a good  way  to  get  going,  but  always  rework  the  first  attempt 
into  a contraint  structure. 

Label  carefully 

Subordination  of  unneeded  details  highlights  the  meaningful  ones. 

Don't  clutter  your  diagrams  with  too  much  Information  and  too 
many  arrows. 


Don't  spend  too  long  on  a single  level,  Everything  need  not  be 
expressed  at  once  to  avoid  being  incomplete  and  misunderstood. 

The  whole  point  of  the  discipline  is  to  get  everything  said, 
eventually. 

Alio,  If  there  is  too  much  in  a diagram,  it  becomes  rigid . If  this 
is  allowed  to  happen,  the  diagram  ia  weakened.  Strength  comes  from  ths 
structure.  This  can  be  accomplished  by  leaving  detaila  to  the  subfunctions. 

Do  iterate  between  high-level  diagrams  and  subfunctiona  that  fill 
out  the  details. 

Leave  out  questionable  arrows 

It  ia  often  hard  to  determine  whether  to  show  an  arrow  or  not. 

The  easiest  way  to  handle  the  arrow  question,  is  "When  in  doubt, 
leave  It  out. 11  If  the  arrow  isn't  really  essential  to  the  main  baokbone,  if 
there  are  questions  about  it,  it  is  probably  incorrect  to  include  It. 

Incorrect  omission  of  a questionable  arrow  now  won't  cause  permanent 
damage.  The  need  for  the  arrow  will  be  dearer  in  con  aide  ring aubf  unctions 
and  the  ICOM  discipline  will  force  the  arrow  back  up  to  this  level.  At  that 
time,  there  will  be  no  question  about  it. 

6.2.3  Level  of  Effort 

The  Initial  goal  In  generating  a diagram  should  be  a clear  diagram 
that  repreaenta  a definite  menage  and  does  not  violate  any  ayntax  rules, 
when  the  diagram  is  finiahed,  the  critical  guidelines  of  reading  and  review 
by  others  can  be  used  to  improve  the  first  try.  Most  diagrams  can  be 
modified  to  make  a second  version  that  is  in  some  sense  better  then  the 
first.  The  first  will  rarely  be  the  very  best. 

As  skill  levels  develop,  first  diagrams  get  better  and  authors  feel 
more  comfortable  using  IDEFq.  Reworking  of  diagrsms  will  slways  be  a 
necessary  part  of  the  process.  The  key  idea  is  to  use  a review  cycle  to 
make  progress  on  paper.  In  a series  of  ordsrly  advances,  all  of  the 
important  aapects  will  be  properly  handled. 


IDEFq  ia  a thought- forming  methodology,  not  juat  a diagram- 
making exerciae,  Putting  thoughts  on  paper  and  letting  the  notation  and 
diacipline  work  is  a move  towards  a satiafactory  resolution.  Rely  on  an 
ability  to  aak  good  qucationa,  rather  than  on  the  expectation  of  providing 
"perfect"  anawera. 

6.3  Redrawing  an  IDEFg  Diagram 

6.3. 1 Modifying  Boxea 

When  firat  creating  a diagram,  3-6  function  boxea  of  approximately 
the  aame  level  of  detail  are  derived.  Clustering  and  splitting  will  provide 
a boundary  which  ia  more  easily  understood  or  which  will  provide  a simpler 
interaction  between  the  function  boxea. 

Moat  often,  clustering  and  splitting  work  together.  Boxea  are 
split  and  the  resulting  pieces  clustered  into  new  boxes  which  more  closely 
convey  the  intended  message.  The  came  subject  matter  is  covered,  but 
pieces  are  grouped  in  a more  understandable  way. 

Split  and  rephrase 

It  is  important  that  aH  of  the  boxes  of  a diagram  have  a consistent 
flavor.  Changes  elsewhere  must  not  make  one  sub  function  seem  out  of 
place.  Split  and  rephrase  to  restore  the  balance. 

Sometimes  a box  does  not  flow  with  the  other  boxes  of  the  current 
diagram. 

Frequently  the  trouble  is  that  other  aspects  have  undergone 
change  and  clarification,  That  which  earlier  was  a good  idea,  now  has 
the  wrong  slant  or  flavor. 

Divide  the  offending  box  by  splitting  it  into  two  or  more  pieces, 
one  of  which  still  contains  the  essence  of  the  original  idea. 

Do  expect  to  change  the  wording  of  the  box  (or  boxes) . With  the 
separation,  new  ideas  become  clearer  and  mesh  more  closely  with  related 
boxea. 


/ 
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Cluster  and  replace 

A solid  abstraction  la  both  clearer  and  more  powerful  than  pre- 
mature detail.  Cluater  related  boxes  and  replace  by  a single  encompassing 
box. 

Frequently  a good  level  of  abstraction  can  be  made  even  better  by 
clustering  several  boxes  into  a more  general  view  and  postponing  the 
details  to  thu  next  level  down.  Draw  a line  around  the  duster  and  replace 
them  all  with  one  box.  suitably  named.  The  extra  level  Is  not  ah  added 
complexity.  It  is  a better  representation  because  the  structure  has  been 
shown  more  clearly. 

This  phenomenon  arises  often  in  conjunction  with  splitting  and  is 
one  of  the  most  powerful  methods  of  explaining  functions. 

6*3.2  Bundling  Arrows 

Both  arrows  and  boxes  should  be  at  a corresponding  level  of 
abstraction  in  a diagram. 

There  are  two  basic  ways  to  achieve  thias 

1.  Bundle  arrows  with  the  same  source  and  destination 
under  a single  more  general  label,  and  make  one  arrow. 

2.  Rename  some  boxes  (using  Split  and  Cluster)  to  better 
distribute the nsuE functions  and  rolabel  resulting  arrows. 

It  is  seldom  true  that  an  excess  of  arrows  indicates  a mistake.  It 
may  be  that  they  are  both  accurate  and  precise.  But  it  in  always  true 
that  an  excess  of  is  bad  if  things  are  obscured.  The  ability  of 
readers  to  understand  what  is  being  said  should  guide  the  number  of 
arrows  used. 
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6.3.3  Propping  Modifications  to  the  Context 

The  detailed  understanding  revealed  by  creating  a new  diagram 
may  uncover  errors  or  oversights  in  the  parent  diagram.  Parent  modi- 
fication is  a natural  and  anticipated  event.  When  oreating  the  arrow 
structure,  the  rule  Is  that  "if  there  is  any  doubt  whether  a data  arrow  is 
needed  by  a function  box,  leave  it  out  — later  detailing  will  demonstrate 
whether  or  not  the  arrow  ia  really  needed,"  This  ia  the  point  where  such 
questions  are  resolved  for  a specific  reason  rather  than  through  former 
speculation. 

Parent  diagram  changes  may  represent  various  degrees  of  difficulty. 
If  the  change  can  be  accommodated  by  a revision  to  the  immediate  parent 
only,  this  Is  simpler  than  a revision  which  involves  more  remote  diagrams 
as  well.  When  proposing  a change,  think  it  through  carefully  and  aaaeas 
ita  complexity,  Substituting  simple  changes  for  major  onsa  can  harm  the 
quality  of  the  decomposition.  When  the  correction  is  completed,  check 
all  boundary  connections  to  insure  that  1COM  codes  are  properly  ehown, 
Inform  other  authors  working  on  the  diagram  of  the  changes, 

Always  have  in  mind  the  parent  diagram  for  the  box  being  detailed, 
It  will  aid  in  the  creation  process . 

If  the  detailed  diagram  doesn't  fit  the  context,  either  the  current 
work  or  the  context  la  wrong,  Change  the  context  or  change  the  current 
work.  They  must  match 
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6.3.4  I COM  Syntax  for  Connacting  Diagrams 

An  Important  aspect  of  understanding  diagrams  is  the  ability  to 
find  and  understand  facts  that  are  needed.  Node  numbers  show  the 
structure  of  the  box  decomposition.  The  arrow  network  provides  inter- 
face connections. 

ICOM  codes  are  written  on  all  arrows  having  one  end  unconnected 
on  the  diagram.  These  boundary  arrows  connect  the  arrow  network 
across  diagrams.  Each  boundary  ./row  is  labeled  with  an  ICOM  code  to 
specify  the  connection  of  the  arrow  to  the  parent  diagram. 

6.  4 Graphic  Layout 

Layout  the  boxes  diagonally  according  to  ths  constraint  structure) 
from  upper  left  to  lower  light)  with  feedback  arrows  going  up  and  left>  At 
this  point,  number  the  boxes  from  left  to  right. 

It  is  best  to  start  this  layout  with  the  moat  heavily  used  constraint 
arrows  only,  adding  leas  used  paths  later.  This  subset  of  the  arrows  will 
permit  the  box  pouition  to  be  determined.  Draw  all  boundary  arrows  shown 
on  the  parent  diagram  and  then  add  the  remaining  arrows, 

6.4.1  Constraints  on  the  Diagram 

1.  When  an  entry  arrow  serves  both  control  and  input 
functions,  show  it  as  control,  When  in  doubt,  make 
it  control.  An  arrow  appearing  on  a parent  diagram 
as  control  can  appear  on  the  next  level  as  control  or 
input  or  both,  depending  on  its  relationship  to  the 
■ubfunction  at  this  level. 


S 


2. 


Function  boxes  must  always  have  control  arrows, 
though  they  may  not  always  have  inputs. 


» 


3.  In  general,  do  not  split  an  arrow  Into  both  a control 

and  an  input  to  the  same  box.  This  detail  is  best  shown 
on  a lower  level  diagram  where  the  destination  of  each 
branch  and  the  reason  for  the  split  will  appear.  When 
it  must  be  done  choose  labels  for  the  two  branches  that 
will  convey  your  important  decision. 


Only  show  it  this  way  if  the  storage  is  to  be  thought 
of  as  being  "at  this  level,"  Otherwise,  show  the  feed- 
back loop  at  the  next  level  of  detail,  that  Is,  "inside" 
the  box, 

5,  Try  to  avoid  redundancies  such  ast 


MAKE 

X , 

Of 

CONSIDER 

X 

X 

In  these  cases  , the  trivial  box  names  merely  repeat  the 
message  conveyed  by  placement  of  the  arrows.  A little 
additional  thought  will  usually  produce  more  informative 
box  names. 


6,4.2  Arrow  Placement 


1.  Draw  arrows  along  horizontal  and  vertical  lines,  not 
diagonally  or  as  curves  (except  at  corners). 

2.  Place  arrow  corners,  intersections,  and  labels  a 
reasonable  distance  away  £rom  boxes. 

3.  Don't  use  the  keywords,  i.e.,  "data,"  "function," 
"input,"  "output,"  "control,"  or  "mechanism"  in 
names  or  labels,  unless  absolutely  necessary. 

4.  if  an  arrow  is  long,  label  it  twice. 


cook 


cook 
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5.  Place  1C0M  codes  at  the  unconnected  ends  of  arrows. 


6. 


Connect  open-ended  boundary  arrows  to  show  all  the 
places  affected.  Readers  may  miss  connections  otherwise. 


r° 

— a 


rather  than 


a 

+ — a 


7,  Don't  draw  arrows  all  the  way  to  the  margins  of  the 
diagram  sheet. 


* 


rather  than 


♦ 


8.  Space  parallel  arrows  adequately.  They  are  hard  to 
follow  visually  If  they  are  lengthy  and  close  together. 

► 


rather  than 

» 

— ■ — * 

'1,  Place  extra  arrowheads  along  arrows  where  needed 
for  clarity. 


* 

* 

* 

* 
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6.4.3  Arrow  Layout 


1. 


Bundle  arrows  with  the  same  source  and  the  same  destina- 
tion unless  the  arrow  is  of  such  importance  that  making 
it  part  of  a pipeline  would  decrease  clarity. 


rathar  than 


2.  On  any  one  side  of  a box,  there  should  never  be  more 
than  four  arrows.  If  there  are  more,  bundle  some, 
label  with  a suitable  abstract  label,  and  fan  out  branches 
to  their  destinations. 

Drm  rathe  r than  I Lega-t 


3.  Control  feedbacks  are  clearer  when  shown  as  "up  and 
over. 11 


Input  feedbacks  are  clearer  when  shown  as 
"down  and  under." 


r°ch 
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If  an  arrow  branches  and  feeds  into  several  boxes,  draw 
it.  at  the  same  relative  ICOM  position  on  each  box,  if 
possible. 


Lay  out  arrows  so  as  to  minimize  unconnected  crossings, 


rsthsr  than 


Minimize  curves  and  corners,  whenever  possible) 


Use  the  expressive  potential  of  branching  arrows  when 
and  if  it  is  appropriate! 
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8.  To  avoid  clutter  when  showing  an  external  arrow  which 
applies  identically  to  or  is  obtained  identically  from 
each  and  every  box  on  a diagram,  use  the  "to  all" 
convention! 


6.  5 Writing  Text 

The  text  that  accompanies  each  diagram  presents  a brief  overview 
of  the  diagram.  It  is  always  less  than  a page  in  length.  It  highlights 
features  that  the  author  feels  are  of  special  interest  or  significance  by 
walking  the  reader  through  the  main  ideas  of  the  diagram.  It  does  not 
duplicate  every  detail  shown  on  the  diagram  itself.  If  the  diagram  conveys 
the  intended  message  sufficiently  well  by  itself,  the  text  may  bn  omitted. 

Write  the  text  only  after  a diagram  has  received  a fairly  high  level 
of  review  and  approval.  Waiting  to  write  the  text  forces  the  diagram  itself 
to  properly  communicate  the  Intended  message.  Text  based  on  carefully 
drawn  diagrams  will  be  as  structured  and  as  organized  as  tho  diagram 
itself, 
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Include  plossary  definitions  to  explain  the  use  of  terms  used  in  the 
diagram.  A word  may  have  different  connotations  from  company  to  company 
and  oven  within  one  company.  For  example,  "directives"  could  emanate 
from  the  design  or  finance  departments,  government,  corporate  policy, 
etc . 

Try  to  get  good  text  without  adding  a FEO.  FEO's  should  be  used 
to  illustrate  subtle  aspects  that  clarify  the  intent  of  a diagram  but  which 
would  clutter  the  diagram  were  they  included.  If  a FEO  is  necessary,  the 
text  that  accompanies  It  should  refer  to  the  related  diagram. 

6.5.1  Writing  the  A-0  Text 

Write  the  A-0  level  text  when  A-0  diagram  is  drawn  and  include  it 
whonevor  A-0  Is  presented.  Since  all  decomposition  proceeds  from  the 
A-0  diagram,  place  any  noteworthy  facts  which  apply  to  the  entire  model 
in  the  text  associated  with  this  diagram.  The  A-0  text  must  contain  a 
discussion  of  the  viewpoint  and  purpose  of  the  model. 


6.5.2  References  and  Notes 

A brief  reference  language  may  be  used  in  writing  text  and  notes 
to  refer  to  diagrams  and  specific  parts  of  diagrams.  For  example! 


02 

means 

The  boundary  arrow  with  ICOM  code  0 

211 

means 

Box  2 Input  1 

202  to  3C1 

means 

The  arrow  from  202  to  3C1 

© 

means 

Note  n 

I 

I 


These  Items  may  be  used  individually  if  they  refer  to  the  current  diagram 
(e.g,,  in  notes  or  text).  Otherwise  they  should  be  preceded  by  node 
number,  and  if  necessary,  by  model  name,  A period  is  used  to  mean 
"see"  a certain  thing  on  the  specified  diagram,  fr  example! 

MODEL/A21. 3C2  means  In  "Model"  on  diagram  A21,  see 

Box  3 Control  2 

A42.  @ means  On  diagram  A42  in  this  model,  see 

note  3 

Each  reference  needs  only  as  much  as  necessary  to  be  completely 
unambiguous,  The  fullest  form  1st 

ACCT/A21(T56)  .102  to  4C3 

which  means  in  model  "ACCT,"  diagram  A21,  version  T56,  "see"  the  arrow 
from  Box  1 Output  2 to  Box  4 Control  3, 

Add  neat  and  complete  references  to  your  text,  glossary  and  FEO 

It  1s  easy  to  bo  exaci  without  causing  the  reader  to  falter, 

When  writing  texts,  scan  the  diagram  continually  to  make  the 
story  interesting. 

Don't  worry  about  adding  references.  That  will  impede  the  flow 
and  make  sentences  awkward. 

When  finished  with  th«  text  go  through  and  add  box-number 
references  to  tie  the  text  to  the  diagram  exactly. 

Most  of  the  timo  a simple  box  number  ("Box  3")  or  a reference  to 
a couple  of  arrows  are  sufficient  ("Box  3,  01  and  C2"),  When  a reader 
needs  to  actually  "See"  the  other  diagram,  use  the  of  the  reference 
language. 


i 
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References  should  be  used  for  clarification.  They  will  be 
unobtrusive  only  if  added  after  the  story-line  text  is  finished. 


6.6  Model  Quality  Checklist 

The  material  presented  in  the  following  sections  provides  definable 
checks  for  constructing  or  evaluating  the  quality  of  IDEF^  models. 


6-6*1  Syntax 

Syntactic  rules  are  constraints  in  the  sense  that  they  deacribe 
logically  what  is  represented  graphically.  Components  of  a diagram 
in  IDEFq  can  be  considered  to  be  primitives  i syntactic  constraints  are 
statements  which  specify  allowable  or  valid  relations  and  operations  which 
affect  these  primitives.  In  short)  a syntactic  constraint  can  be  thought 
of  as  a criterion i if  the  constraint  is  not  satisfied)  or  is  violated  in 
the  graphic  display,  the  criterion  has  not  been  met,  and  the  resulting 
diagram  or  model  is  deficient  with  respect  to  that  particular  constraint. 

At  least  three  different  types  of  syntactic  constraints  are 
distinguished,  depending  on  the  level  of  analysis  or  level  of  graphic 
representation  that  is  being  addressed) 

1)  Local  Construction) 

These  rules  pertain  to  simple,  first-order  combinations  or 
associations  of  primitives.  They  are  defined  for  FEO's 
and  diagrams,  and  must  be  followed  for  valid  construction. 
Diagrams  having  missing  components  or  showing  relations 
among  primitives  other  than  those  stated  below  are  "invalid 
syntactically. " 

2)  Global  Construction  i 

These  rules  pertain  to  whole  diagrams,  but  not  to  text 
or  FEO's.  Thus,  they  are  defined  over  several  con- 
structions, and  can  be  verified  only  after  the  diagram 
has  been  completed. 

3)  Model  Construction) 

Constraints  In  this  category  specify  the  layout  of 
nodes  and  numbering /lettering  designations  that 
create  an  ordered  hierarchy  among  diagrams. 
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The  following  checklists  can  be  used  as  guidelines  for  determining 
a minimum  level  of  acceptability  for  IDEFQ  diagrams  and  models.  Deficiencies 
can  be  pinpointed  at  the  local,  global  or  whole  model  level.  "Completeness" 
and  "correctness"  are  identified  here  as  overall  evaluation  standards  that 
must  be  met.  Working  definitions  (for  IDEFQ  syntax)  appear  below i 
COMPLETENESS 


DECREE  TO  WHICH  ALL  REQUIRED  FIELD-ENTRIES. 
LABELS.  BOXES.  ARROWS.  AND  IDENTIFYING 
NOTATIONS  ARE  PRESENT  IN  A DIAGRAM  OR  MODEL. 


CORRECTNESS 


DEGREE  TO  WHICH  A DIAGRAM  OR  MODEL  HAS  BEEN 
ACCURATELY  CONSTRUCTED.  LABELLED,  AND 
IDENTIFIED;  I.E.,  DECREE  TO  WHICH  SYNTACTIC 
RELATIONS  HAVE  BEEN  REPRESENTED  APPROPRIATELY 
IN  THE  GRAPHICS.  AND  CONSTRAINTS  OBEYED. 


CHECK  FOR  ADHERENCE  TO  CONSTRAINTS  ITEM  BY  ITEM. 
(SEE  SECTIONS  6.6.1. 1,  <.6.1.2,  and  6. 6.1. 3). 


MEASURES 


DEFINITION 


DEFINITION 


6.6. 1.1  Local  Construction  Syntax 

a.  One  way  arrow  seamen ta  are  made  up  of  ordered  pair# 
of  endpoints  (SOURCE,  SINK),  where i 

SOURCE  points  are  one  of: 

boundary  endpoint  near  diagram  I,  C,  or  M boundary 
box  endpoint  on  Box  0 side 
fork  sink 
join  sink 
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SINK  points  are  one  of: 


boundary  endpoint  near  diagram  O boundary 
box  endpoint  on  Box  I,  C,  M side 
join  source 
fork  source 

Note  that  all  combinations  are  legal  except  a (diagram 
boundary,  diagram  boundary)  arrow. 

b.  Arrow  labels  are  associated  with  arrow  segments. 

Line  squiggles  may  be  used  to  clarify  the  association. 

c.  Each  ICOM  code  from  the  parent  box  must  be  associated 
with  the  Boundary  endpoint  of  some  arrow. 

d.  Boxes  can  have  an  integer  number.  Box  numbers 
start  at  1 and  increase  by  1. 

e.  Names  are  associated  with  boxes  and  cannot  stand  alone. 

f . Endpoints  or  arrows  at  diagram  boundaries  have 
tunnel  11  ( ) 11  or  an  I C 0 M but  not  botfiT 

a.  Endpoints  of  arrows  at  box  endpoints  can  have 

■ II  I'  * H"  >-*""<  II  1 «■■-»»■  tJmrnm — — — 

tunnels  11  ( PP 


6.6. 1.2  Global  Construction  Syntax 

e A finished  IDEF  diagram  consists  of  no  less  than  three 
an cT no  more  than  six  boxes,  unless  it  is  an  A-0 
diagram  in  which  case  it  contains  exactly  one  large 
box . 

• Each  box  must  be  named  and  numbered,  On  each  diagram 
the  numbers  start  at  one  and  increase  monotonlcally 

by  one.  The  box  on  an  A-0  diagram  is  numbered  0.  No 
two  boxes  on  one  diagram  can  have  the  same  number. 

• Each  box  must  have  at  least  one  arrow  source  at  its  O 
(right)  sUe  and  one  arrow  sink  at  Its  ti  (top)  side, 

• All  endpoints  of  arrow  segments  at  diagram  boundaries 
must  have  either  an  ICOM  code  or  tunnel  "(  )”,  except 
on  an  A-0  diagram  (or  which  there  are  neither  ICOM 
codes  nor  turnel  "(  )''. 


6.6. 1.3  Model  Construction  Syntax 


Rules  and  Conventions  for  Valid  Model  Structure  In  IDEFq 

A model  Is  a hierarchically  structured  collection  of  nodes 
representing  successive  refinements , each  of  which  may  be  detailed  on 
one  or  more  diagrams.  The  top  node  of  the  IDEFq  diagrams  in  a model 
is  designated  AO.  A box  has  a node  number  derived  by  appending  the 
box  number  to  the  node  number  of  the  diagram  on  which  the  box 
appears.  A diagram  has  the  same  node  number  as  (is  the  same  node  as) 
the  box  it  details.  However,  when  appending  the  box  number,  the  "0" 
(from  the  AO  node)  is  treated  as  "null11  and  dropped.  For  example,  the 
decomposition  of  Box  2 on  the  diagram  detailing  node  AO  is  designated 
A2.  Also  the  decomposition  of  Box  1 on  the  diagram  detailing  node 
A2315  is  designated  A23151. 

A FEO  that  illuminates  an  IDEF  diagram  is  designated  by  concaten- 
ating the  letter  F to  the  right-hand  end  of  the  designator  of  the  diagram, 
Text  or  glossary  that  illuminates  an  IDEF  diagram  or  FEO  is  designated 
by  concatenating  the  letter  T or  C,  respectively,  to  the  right-hand  end 
of  the  designator  of  t'he  diagram  or  FEO.  For  example,  the  FEO 
illuminating  Box  3 of  node  A21  would  be  designated  A213F.  Text 
illuminating  node  A114  would  be  designated  A114T.  Text  illuminating 
FEO  A31F  would  be  designated  A31FT.  Glossary  definitions  for  terms 
used  on  diagram  A114  would  be  designated  A114G,  etc,  Additionally, 
if  there  is  more  than  one  illuminating  FEO  or  glossary  page,  a 
sequence  number  is  concatenated  to  the  right  of  the  letter  F,  or 
G.  Thus,  the  two  FEO's  illuminating  diagram  A213  would  be  designated 
A213F1  and  A213F2. 

Although  the  top  node  of  an  IDEF  function  model  is  always  AO, 
there  are  other  nodes  at  a "higher"  level  used  to  show  context  and 
environment.  The  A-Q  (A  minus  zero)  shows  the  context  of  AO,  The  A-0 
box  may  be  shown  in  an  A-i  diagram,  etc. 


i i 
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The  interconnections  between  parent  and  child  arrows  are 
maintained  through  the  use  of  ICOM  codes.  The  ICOM  occurrences  are 


represented  explicitly  on  the  child  diagram  at  the  diagram  boundary  point 
of  an  arrow.  The  corresponding  ICOM  on  the  parent  box  ia  determined 
implicitly  from  the  position  of  the  arrow's  context  point.  The  letter 
(I,  Ci  Oi  or  M)  corresponds  to  the  side  of  the  box  on  which  the  context 
point  occurs.  This  is  followed  by  a number  determined  by  the  order  in 
which  the  arrow  appears  on  that  side  of  the  box  (counting  top  down  and 
left  to  right) . Note  that  ICOM  codes  will  change  as  arrows  are  added, 
deleted,  or  moved  on  the  parent  box. 

6.6.2  Semantics 

"Semantics"  is  a term  that  has  been  applied  to  a.  wide  range  of 
factors,  all  of  which  have  some  effect  on  the  "meaning"  of  labels, 
diagrams,  and  models  in  IDEF^.  In  order  to  establish  criteria  useful  for 
evaluating  models,  those  aspects  of  "meaning"  that  relate  to  the  consistent 
and  unambiguous  naming  of  data  and  function  in  IDEF^  will  be  dealt  with. 
Criteria  for  evaluating  the  overall  "story,"  "message,"  or  "sense"  of  a 
diagram  or  model  will  be  addressed  in  terms  of  accessing  complexity, 

At  least  five  types  of  semantics  should  be  evaluated.  There  arei 

1.  COMPLETENESS 

2.  CONCISENESS 

3.  CONSISTENCY 

4.  CORRECTNESS 

3.  COMPLEXITY  /UNDERSTANDAB ILITY 

Each  of  these  criteria  is  considered  separately  in  the  summary 
sections  that  follow, 
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Completeness 

One  useful  measure  for  evaluating  the  adequacy  of  information- 
coverage  is  amplification . This  refers  to  the  degree  to  which  additional 
details  are  introduced  in  a child  diagram , relative  to  its  parents  Ideally, 
there  should  be  sufficient  detailing  introduced  to  make  the  parent  more 
comprehensive  in  information  content  — • but  not  so  much  detail  that  the 
overall  model  becomes  complex  and  harder  to  understand.  Also,  there 
should  bo  a balance  between  the  degree  of  detail  conveyed  by  the 
function-box  labels,  and  that  expressed  by  data  arrow  labels.  A diagram 
with  very  general  ana  abstractly-labelled  function  boxes,  but  with 
minutely  detailed  labels  on  the  data  arrows  ia  unbalanced  semantically) 
the  amplification  factor  might  also  be  low  on  successive  child  diagrams 
because  there  would  be  limited  room  to  do  further  detailing  on  data  arrow 
labels. 


Definitions  and  M< 


DEFINITION 


SUFFICIENCY  OF  INFORMATION  CONTENT  TO  COVER 
SUBJECT  MATTER  (CONTEXT) 


MEASURES 

AND 

“ARAMETERS 


DIAGRAM  LEVEL:  FOR  ANY  DIAGRAM,  EXCEPT  THE 
TOPMOST  - DEGREE  OF  ADEQUATE  COVERAGE  OF 
INFORMATION  WITH  RESPECT  TO  THE  BOUNDED  CONTEXT 
ON  THE  PARENT. 


Ill 


(PARENT) 


WHOLE  MODEL  LEVEL*. 

DECREE  OF  DECOMPOSITION  OF  BOXES. 

[VARIES  ACCORDING  TO  PURPOSE  OF  MODEL; 

AMOUNT  OF  DETAILING  NEEDED  TO  FULLY  COMMUNICATE  THE  PURPOSE) 

DECREE  OF  DETAILING  OF  ARROWS  FROM  TOP  TO  LOWEST 

LEVEL  IN  A MODEL 

[VARIES  WITH  LEVEL  OF  DETAIL  AND  ABSTRACTION  OF 

FUNCTION  BOXES] 

Conciseness 

The  "information  value"  of  labels  and  titles  in  IDEFg  1®  ultimately 
the  potential  relevance  of  the  diagram  content  to  the  reader.  For  this 
reason,  authors  should  strive  to  select  label  names  that  are  in  common 
use,  especially  if  they  are  associated  with  technical  processes  or  practices 
in  the  manufacturing  environment.  The  words  used  on  diagrams  and  in 
accompanying  texts  should  also  be  natural , ip  the  way  they  relate  to 
the  anticipated  rrader-audience , For  example,  an  audience  of  accountants 
would  relate  to  labels  such  as  "indirect  labor,"  "direct  labor,"  and 
"G&A  overhead,"  but  project  managers  may  prefer  terms  such  as 
"billable  labor,"  'internally  funded  research,"  and  "support  labor," 
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"Degree  of  redundancy"  is  difficult  to  measure  when  simply  reading 
over  a diagram  or  series  of  diagrams,  If  authors  provide  a glossary  of 
key  terms,  and  provide  sufficiently  detailed  listings  of  characteristics 
or  properties  of  technical  terms,  readers  and  reviewers  would  have  a 
more  objective  means  for  deciding  when  two  labels  are  just  two  different 
words  for  the  same  thing,  or  whether  they  really  name  different  things. 

IDEFq  labels  are  candidate  IDEF^  entity  and  attribute  class  names) 
if  an  entity  class  is  used  as  an  IDEFq  arrow  label,  attributes  of  the  entity 
class  can  aid  in  determining  the  precise  arrow  contents,  and  can  be  used 
to  understand  and  compare  arrows,  Attribute  listings  for  entities  named 
in  diagrams  would  be  a useful  addition  to  glossary  formats,  Given  an 
attribute  listing,  "redundancy"  could  be  assessed  by  the  degree  of 
overlap  between  sots  of  attributes . 

Definitions  snd  Measures 


DEFINITION 


PRECISION  OF  INFORMATION  CONTAINED  IN  AND/OR 
CONVEYED  BY  A DIAGRAM  OR  MODEL;  APPROPRIATENESS 
OF  TERMINOLOCY  AND  SYMBOLOGY.  ABSENCE  OF 
INFORMATION  PERIPHERAL  TO  MODEL'S  ORIENTATION. 


MEASURES 

AND 

PARAMETERS 


INFORMATION  VALUE  OF  LABELS,  TITLES.  AND 
FUNCTION  NAMES 

DEGREE  OF  REDUNDANCIES  IN  LABEL  NAMES 
NATURALNESS  OF  TERMINOLOCY:  TO  FIT  — 
e SUBJECT  MATTER 

e AUDIENCE 
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Consistency 

The  syntactic  checks  discussed  earlier  would  serve  to  verify  the 
graphic  notations  that  help  convey  consistency  in  labelling  and  trace- 
ability  of  data  arrows  throughout  the  hierarch'y  of  a model.  The  degree 
that  the  content  of  the  model  is  consistent  is  more  a matter  of  judgement 
on  the  part  of  reviewers  and  experts  in  the  subject  matter  being  modelled. 

Consistency  of  naming,  however,  in  the  case  of  function  box  and 
arrow  designations,  might  be  facilitated  if  attribute  listings  were  provided 
as  part  of  glossaries  with  a diagram  or  model. 

Definitions  end  Meggy  res 


DEFINITION 


MEASURES 

AND 

PARAMETERS 


e INTERNAL:  DECREE  OF  UNIFORMITY  OF  NOTATION. 

SYMBOLOGY,  AND  TERMINOLOCY 
(WITHIN  THE  MODEL) 

e EXTERNAL:  DECREE  THAT  CONTENT  IS  TRACEABLE 
TO  THE  SYSTEM  BEING  MODELED. 
(OUTSIDE  THE  DIAGRAM  OR  MODEL) 

e CORRECTNESS  OF  ICOM  LABELS:  PLACEMENT  AND 
TRACEABILITY  THROUGH  THE  HIERARCHY 

• CORRECTNESS  OF  TUNNEL  ( ) USE 
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Correctness 


"Correctness"  is  perhaps  the  most  subjective  of  the  semantic 
characteristics  presented  in  this  section , chiefly  because  the  final 
standard  for  assessment  must  come  from  the  opinion  of  individuals  who 
have  the  most  complete  knowledge  of  the  subject  matter  being  modelled. 
The  kit  cycle  in  IDEFq  has  been  designed  to  assist  the  construction 
of  models  that  can  be  judged  "correct"  on  the  basis  of  peer-review,  as 
well  as  by  evaluation  by  technical  experts, 

Definitions  and  Measures 


DEFINITION 


e EXTENT  TO  WHICH  INFORMATION  EXPRESSED  IN  A 
DIAGRAM  OR  MODEL  IS  AN  ACCURATE  DESCRIPTION 
OF  THE  SYSTEM  BEING  MODELED. 

e DEGREE  TO  WHICH  IMPLIED  CONSTRAINT  RELATIONS 
AND  DATA-TO-FUNCTION  INTERFACES  REPRESENT 
VALID  RELATIONS. 


MEASURES 

AND 

PARAMETERS 


REVIEW  OF  MODEL  BY  EXPERTS 

CHECKS  IN  COMPANY  LITERATURE  OR  TEXTBOOK 
SOURCES  FOR  TERMINOLOGY  AND  TECHNICAL 
USAGE. 
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Complexity /Undoratandabl  lit  y 

"Understandability " Is  an  important  but  difficult  criteria  to 
measure  in  assessing  model  quality,  mainly  because  of  its  abstract  and 
subjective  connotations,  Another  source  of  the  problema  associated  with 
measuring  "understandability"  is  the  strong  interrelationship  of  syntactic 
and  semantic  factors . Since  we  are  defining  "underetandability"  aa  a 
function  of  how  well  the  content  of  the  model  is  portrayed  via  the  ayntax, 
the  relevant  measures  would  be  derived  from  both  ayntax  and  semantical 
No  single  feature  of  semantics  would  therefore  appear  to  be  a sufficient 
index  of  how  well  an  evaluator  could  understand  a complete  model. 

Measuring  "complexity,"  however,  is  a more  feasible  task.  We  are 
suggesting  that  "understandability " and  "complexity"  be  viewed  aa  dual 
measures  - i.e.,  something  that  is  highly  complex  can  be  expected  to 
be  hard  to  understand)  and  similarly,  something  that  has  a low  complexity 
value  is  probably  much  more  accessible  to  a user  and  more  easily  under- 
stood. 

Definitions  and  Measures 


DEFINITION 


MEASURES 

AND 

parameters 


EXTENT  TO  WHICH  PURPOSE  OP  MODEL  OR  DIAGRAM  IS 
CLEAR  TO  THE  EVALUATOR. 

DECREE  TO  WHICH  "WHAT  THE  MODEL /DIAGRAM  SAYS" 

IS  ACCURATELY  DEPICTED  VIA  THE  SYNTAX. 

EASE  OF  FINDING  THE  "MAIN  PATH;'1 
NUMBER  OF  AC  Tl  VAT  IONS /BOX  i 
NUMBER  OF  POTENTIAL  SCENARIOS; 

FACILITY  OF  IDENTIFYING  ACTIVATIONS  AND  SCENARIOS; 
EASE  AND  SUCCESS  OF  "REFINING  THE  LAYOUT;'1 
COUPLING  AND  COHESION  RATING  SCHEME 
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Another  measure  that  would  be  useful  to  IDEF^  authors  and 
commenters  is  ease  with  which  the  layout  on  a diagram  can  be  refined. 
"Refining  the  layout"  is  defined  here  as  the  procedure*  that  are  necessary 
to  disambiguate  the  message  of  a diagram  or  model,  as  it  is  conveyed  by 
the  pattern  of  the  function  box  and  data-arrow  interfaces.  As  a model 
becomes  more  and  more  complex,  and  thereby  less  and  less  understandable, 
the  task  of  refining  the  layout  becomes  more  complicated.  Rules  for 
refining  the  layout  of  a diagram  to  reduce  its  complexity  are  presented 
as  follows  i 


Boundary  arrows  with  more  than  one  ICOM  code  must 
be  split  so  that  each  ICOM  has  its  awn  arrow. 

Cl  C3  C« 


C1.C3.C4 


Figure  6-2.  Arrows  with  more  then  one  ICOM  code 


11? 


Boundary  arrows  having  the  same  ICOM  codes  must  be 
connected , 


BEFORE  AFTER 

Figure  6-3.  Connecting  Boundary  Arrow* 


Arrow  names  that  change  from  parent  diagram  to  child 
diagram,  but  still  represent  the  same  data,  must  be 
reconciled  by  the  author.  The  appropriate  names  must 
be  determined  by  the  author  and  used  consistently 
throughout  the  model. 


M***t 


CD 


Ami 

Figure  6-4.  Arrow  Labels  Remain  the  Same 
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When  dealing  with  arrows  that  split  and  Join,  any 
unnamed  line  segments  must  be  explicitly  named  by 
author. 


The  name  of  this  segment  can  be 
deduced  to  be  "products,  " so  that 
the  explicit  naming  of  the  arrow 
le  not  necessary,  unless  the 
decomposition  of  box  1 shows 
the  arrow  to  have  a name 
different  from  "product!,  " 


The  name  of  this  segment 
cannot  be  easily  deduced  without 
understanding  of  the  model  (it 
could  be  A,  or  D,  or  part  of 
both).  The  name  must  be 
specified  by  the  author, 


Figure  6-6.  Label  Arrow  Splits 
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6.6.3  Relationship  Between  Coupling  and  Cohesion 

Coupling  describes  the  degree  of  Interconnectedness  among 
components,  For  IDEF^,  one  could  describe  the  number  and  types  of 
connections  between  and  among  function  boxes  on  a single  diagram  as 
interconnections  among  components,  Cohesion  describes  the  degree  of 
relatedness  of  subparts  within  a given  part.  For  IDEFq,  "cohesion" 
would  therefore  be  a meaningful  property  to  use  in  evaluating  the 
manner  in  which  functions  are  grouped  together  in  a single  diagram, 

The  relevancy  of  these  measures  to  assessing  complexity  is  as 
follows  i 

"When  components  of  a diagram  or  modal  are  highly  coupled 
to  each  other,  the  model  is  more  complex.  When  components 
are  composed  of  unrelated  (tncohesive)  elements,  the  model 
le  more  complex." 

Thus,  IDEFQ  diagrams  ehould  become  more  understandable  if  their 
components  are  loosely  coupled,  but  fall  into  functionally  relatable  and 
cohosive  patterns, 

6.6.4  Metrics  Based  on  Coupling  and  Cohesion 

The  understandability  of  a model  Increases  and  complexity 
decreases  as  cohesion  Increases  and  coupling  decreases.  It  follows 
that  metrics  based  on  types  of  coupling  and  cohesion  will  be  useful 
for  assessing  the  understandability /complexity  of  IDEFq  models.  Having 
a scale  or  code  to  Identify  different  types  of  coupling  and  cohesion  will 
also  provide  model  authors  with  a tool  that  they  can  use  in  constructing 
models  which  are  more  understandable  and  less  complex. 

6.6. 4.1  Relation  to  Other  Systems  Engineering  Properties 

There  are  several  additional  advantages  that  can  be  gained  by 
establishing  a metric  to  assess  the  types  of  coupling  and  cohesion  in 
IDEF  models,  In  particular,  It  will  be  easier  to  transition  an  ' AS  IS" 
system  description  to  a "TO  EJE"  status  if  coupling  Is  reduced,  thereby 


restricting  the  number  of  module  connections  so  that  as  few  modules  as 
possible  depend  directly  on  the  same  assumptions . * 

The  systems  engineering  principle  of  hiding  describes  the  same 
situation!  information  known  only  to  a given  set  of  modules  Is  said  to  be 
hidden  (or  isolated)  from  other  modules.  The  advantage  of  information 
hiding,  like  reduced  coupling,  is  to  facilitate  local  changes  in  a model  or 
a system  design,  without  having  to  change  as  many  modules  or  components 
as  might  otherwise  be  necessary.  There  is,  then,  a direct  relationship 
between  hiding  and  coupling,  and  an  assessment  of  the  degree  of  coupling 
within  a particular  model  will  provide  information  about  the  extent  of 
information  hiding  as  well. 

Just  as  hiding  appears  to  be  isomorphic  to  coupling,  localization 
is  isomorphic  to  cohesion,  Localization  is  a principle  describing  the  value 
of  bringing  elements  together  in  physical  proximity  — the  benefit  of 
this  principle  Is  to  minimize  redundancies  that  might  otherwise  occur  if 
the  same  information  has  to  be  stated  over  again  In  many  scattered  sites, 
For  example,  consider  the  potential  value  of  identifying  generic  manu- 
facturing subsystems  from  the  ICAM  "AS  IS"  Architecture  (Function 
Model  of  Manufacturing)  . Localizing  those  functions  relating  to  manu- 
facturing control  and  materials  management  in  a separate  function  model, 
for  Instance,  will  facilitate  a transition  to  a "TO  BE"  environment  because 
the  relevant  functions  and  data  have  been  put  into  functional  and 
physical  proximity,  and  can  therefore  be  viewed  as  a separate,  but 
integral  unit.  When  changes  in  the  environment  are  anticipated,  it  would 
be  considerably  more  difficult  to  have  to  trace  all  possible  side  effects  on 
functions  that  are  dispersed  throughout  the  Architecture. 


♦Where  "module  connections"  can  be  interpreted  as  the  function/ 
data  interfaces  on  an  IDEF^  diagram, 


6. 6. 4. 2 Measures  and  Types  of  Couptlnq 

For  purposes  of  this  discussion,  differences  in  types  of  coupling 
will  be  illustrated  by  examining  connections  between  functions  in  IDEFg. 

•.6.4.2. 1 Viewpoint  of  the  Description 

Traditionally  in  the  systems  engineering  literature,  the  coupling 
between  functions  can  be  analysed  from  two  points  of  viewt  the  first 
considers  the  nature  of  the  data  in  the  connoction,  and  the  second 
identifies  the  relations  among  many  tokens  or  examples  of  data  in  a 
connection, 

Figure  6~?  below  displays  this  dual  viewpoint  analysis,  The  terms 
used  under  each  category  are  those  found  in  the  literature,  and  their 
technical  meaning  will  be  treated  in  the  following  pages. 

Nature  of  Connection  Structure  of  the  Connection 
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Normal 

Coupled 
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Figure  G-7.  Analysis  of  Coupling  Between  Functions 
6. 6. 4. 2. 2 Nature  of  Connections 

Pathological ; The  Least  Desirable 

Two  functions  are  said  to  be  "pathologically  coupled"  if  one 
function  references  the  contents  of  the  other,  This  situation  occurs  when 


the  hiding  principle  haa  failed  to  apply.  Aa  an  example,  consider  Figure  6-8, 


Figure  6-8.  Pathological  Coupling 

A data  arrow  going  between  boxes  1 and  2 ia  "pathological"  and  the  boxes 
are  "content-coupled"  by  this  definition,  Clearly,  the  effect  of  box  2 
removes  the  required  materials  that  the  activity  in  box  1 needs  to  operate 
with,  and  connections  of  this  type  are  usually  not  desirable , unless  other 
factors  supply  qualifications, 

Control 

Two  functions  are  "control  coupled"  if  data  from  one  influences  the 
flow  of  control  of  the  other.  Flow-of-control  is  to  be  distinguished  from 
a control-arrow  on  a box,  "Control"  in  this  context  refers  to  the  kind 
of  data,  not  its  position  on  a box.  Control  coupling  occurs  when  a 
function  generates  a controlling  effect  on  another  function's  behavior. 

This  kind  of  coupling  can  be  spotted  hy  noting  function-names  that 
produce  "flags"  along  with  an  intended  functions,  such  as  "Record  failure/ 
print  error  message." 

Normal 

Two  functions  are  "normally"  coupled  if  the  data  connections 
between  them  exist  independently  of  the  contents  of  either  function,  or  if 
there  is  no  influence  on  the  flow-of-control  from  one  function  to  the 
other.  This  type  of  coupling  is  the  most  desirable  kind  of  connection, 
since  communication  between  functions  is  via  explicitly-shown  data,  and 
not  via  Implicit  references  to  the  contents  of  one  or  the  uther  functions. 
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Environmental 

Two  functions  are  environmentally  coupled  if  they  both  reference 
a generic  data  source,  without  clearly  specifying  the  relation  of  a 
particular  piece  of  data  to  any  box.  This  situation  can  be.  represented  by 
the  diagrams  in  Figure  6-9. 


Figure  6-9.  Environmental  Coupling 

Problems  resulting  tv  jm  environmental  coupling  include  the  following! 

1)  The  hiding  principle  is  violated.  Access  it  not 
restricted  to  onlv  the  necessary  data. 

2)  Localization  is  violated.  Data  is  not  a?tociated 
only  with  its  users. 

3)  Error  propagation  is  iiv.veased , potentially. 

Changes  tj  the  environment  may  affect  all 
function?,  unpredlctahly . 


Record 


Two  or  more  functions  are  record-coupled  if  they  reference  a non- 
global  set  of  data,  and  do  not  necessarily  depend  on  having  all  possible 
interfaces  displayed,  as  in  environmental  coupling.  An  IDEF^  example 
appears  in  Figure  6-10. 
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Figure  6-10.  Record  Coupling 

The  type  of  interface  pattern  shown  here  is  preferred  because  the  rela- 
tion of  a particular  data  element  to  each  box  has  been  specified. 

Abstract 

Two  elementa  have  abstract  coupling  if  the  relation  between  a 
particular  element  and  its  potential  "constituents"  has  been  clearly 
specified.  In  IDEFq,  a data  arrow  on  a parent  diagram  that  gets  broken 
down  into  detail  componenta  on  chili  diagram  represents  an  abstract 
coupling  relation.  Hiding  is  in  effect,  Insofar  as  the  parent-level  arrow 
is  "using  the  power  of  abstraction"  to  provide  access  to  the  level  of 
abstraction  required  for  more  complete  understanding  of  the  data  contents. 
The  notion  of  "arrow  pipelines"  in  IDEFq  corresponds  to  this  use  of  abstract 
coupling,  and  should  be  maxlmiied  when  constructing  diagrams. 


6.6.5  Measuraa  and  Type*  of  Cohesion 


Whereas  "coupling"  refers  to  the  connections  between  elements 
(functions  or  data) , "cohesion"  will  be  used  to  reference  the  binding  or 
internal-relatedness  between  factors  on  a diagram. 

At  least  seven  types  of  binding  have  been  distinguished  in  the 
literature . 


Relative  Value 


Coincidental 

Logical 

Temporal 

Procedural 

Cor  munlcatlonal 

Sequential 

Functional 


Worse 


Better 


Each  type  will  be  identified  briefly,  and  illustrated  by  way  of  a 
sketch  of  a typical  example  in  IDEFg. 

(0)  Coincidental;  Least  Desirable 

Coincidental  cohesion  occura  when  there  is  little  or  no  constructive 
relationship  among  the  .dements  of  a module.  This  situation  obtains 
when  the  duta  names  on  IDEFq  arrows  in  a single  diagram  bear  little 
relation  to  each  other.  The  extreme  version  of  this  case  is  shown  in 
Figure  6-11.  I 


Figure  6-11.  Coincidental  Binding 
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( 1)  Logical 

Logical  binding  occurs  when  the  data  and  functions  seem  to  have 
been  gathered  because  they  fit  into  a common  class  or  set  of  elements  — 
but  no  necessary/ functional  relation  can  usually  be  identified. 

Figure  6^12  illustrates  the  typical  cause  of  logical  binding. 
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Figure  6-12.  Logical  Binding 


(2)  Temporal 

Temporally  bound  elements  appear  to  be  clustered  because  they 
represent  functions  associated  in  time  --  data  are  used  simultaneously, 
or  functions  are  performed  In  parallel,  rather  than  in  series.  A frequent 
example  can  be  found  in  diagrams  showing  functions  all  concerned  with 
"initialize"  operations,  as  pictured  in  Figure  6-13, 


Figure  6-13.  Temporal  Binding 


( 3)  Procedural 


Procedurally-bound  elements  appear  grouped  together  because  they 
are  executed  or  performed  during  the  same  part  of  a cycle  or  process. 

The  common  unit  of  process  may  be  an  iteration  or  decision-branch,  or  a 
linear  ordering  of  steps.  An  example  of  a procedurally-bound  diagram 
is  given  in  Figure  6-14. 


Figure  6-14.  Procedural  Binding 

In  this  diagram,  the  boxes  are  clustered  because  both  outputs,  A ft  B , 
are  necessary  before  some  function  downstream  can  proceed,  Note  that 
boxes  1 and  2 have  no  other  influence  on  each  other,  and  they  are 
thereby  bound  by  their  relation  to  the  process  in  box  3. 

(4)  Communications! 

Diagrams  exhibit  communicational  binding  when  boxes  have  been 
grouped  because  they  use  the  same  input  data  and/or  produce  the  same 
output  data.  This  is  the  first  type  of  binding  discussed  thusfar  which 
represents  the  preferred  level  of  binding  for  IDEF^.  One  important 
reason  is  that  none  of  the  levels  of  cohesion  discussed  above  is  very 
closely  tied  to  the  structure  of  a particular  problem,  Communicational 
cohesion  is  the  lowest  level  at  which  we  encounter  a relationship  among 
processing  elements  which  is  intrinsically  problem-dependent. 

Figure  6-15  illustrates  the  typical  case. 
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Figure  6- IS.  Communication*!  Binding 


(S)  Saquantlal 

Diagram*  having  sequential  binding  have  output  from  one  function 
serving  as  input  data  for  the  next  function.  The  relationship  among 
elements  on  a diagram  is  more  interrelated  than  at  previously-mentioned 
binding  levels,  insofar  as  cause-and-effect  transforms  of  data  are  being 
approximated.  Hence,  the  high  rating.  Figure  6-16  illustrates  sequential 
binding , 


Figure  6-16.  Sequential  Binding 


(6)  Functional 

A diagram  exhibits  complete  functional  binding  when  all  elements 
of  a function  contribute  to  the  performance  of  a single  function  or  result. 
A diagram  that  is  purely  functional  contains  no  extraneous  elements 
related  by  sequential  or  weaker-valued  types  of  binding.  One  way  to 
identify  functionally-bound  diagrams  is  to  look  for  two  boxes  linked  via 
control  arrows,  as  illustrated  in  Figure  6-17. 


Figure  6-17.  Funetlonsl  Binding 


In  mathematical  terms,  the  requirement  for  the  simplest  type  of 
functional  binding,  shown  in  Figure  6-17.  is  as  follows t 

C « g(b)  ■ g (f ( A) ) 

Other  useful  checks  for  functional  binding  include  clues-by- 
elimination.  The  guidelines  that  follow  are  meant  as  aids  to  help  authors 
and  reviewers  distinguish  functional  from  non- functional  binding. 

e If  the  only  reasonable  way  of  describing  a diagram 
is  by  using  a compound  sentence,  or  a sentence 
containing  a comma,  or  a sentence  containing  more 
than  one  verb,  then  the  diagram  is  probably  less 
than  functional,  It  is  probably  sequential , 
comniunlcational.  or  logical  in  terms  of  cohesivenesa. 
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• If  the  descriptive  sentence  contains  such  time- 
oriented  words  as  "first,"  "next,"  "after," 

"then,"  "start,"  "step,"  "when,"  "until,"  or 
"for  all,"  then  the  diagram  probably  has 

temporal  or  procedural  cohesion,  sometimes,  I 

but  less  often,  such  words  are  indicative  of 

sequential  cohesion.  j| 

e Tf  the  predicate  of  the  descriptive  sentence  does  not 
contain  a single  specific  object  following  the  verb, 

the  diagram  is  probably  logically  cohesive.  i 

i 

Summary 

Figure  6-18  contains  a summary  of  the  types  of  binding  treated 
in  the  previous  sections.  The  important  point  to  note  is  that  levels  4-6  : 

constitute  the  types  of  binding  that  IDEF^  developers  consider  critical 
for  having  "quality"  diagrams.  Authors  should  strive  to  maximise  the 
presence  of  these  binding-types. 


6.6.6  Assessing  Coupling  end  Cohesion  In  1DEF 

The  rating  scales  presented  here  were  originally  developed  to 
assist  systems  engineers  in  selecting  among  design  alternatives,  and  to 
clarify  the  relative  desirability  of  alternate  decompositions.  The  use  of 
similar  scales  Is  being  proposed  for  IDEFq  as  an  aid  to  authors  and 
comnionturs  for  ensuring  the  quality  of  models. 

A few  additional  observations  are  in  order,  in  the  light  of  these 
objectives  i 

• With  relevance  to  IDEFq,  "coupling"  and  "binding" 
are  really  versions  of  tne  same  concept,  but  differ 
because  they  apply  to  distinct  components  of  models, 
"Coupling"  can  be  used  to  compare  the  complexity 
of  connections  between  diagrams,  or  between  boxes 
on  a parent  diagram. 

"Binding"  can  be  used  to  assess  the  strength  of 
the  links  among  different  boxes  within  a diagram, 
or  to  measure  the  cohesiveness  of1  the  parent  box 
of  a diagram. 
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6-18.  Cohesion:  Levels  of  Binding 


I 


• Immediate  dues  for  identifying  undesirable  connections 
can  bo  found  by  noticing  tight  coupling  on  a parent 
diagram.  This  usually  indicates  low-valued  binding 
(incohesionl  on  child  diagrams.  An  author  can 
improve  the  quality  of  the  model  — and  make  the  set 
of  parentichiid  diagrams  more  understandable  by 
re-decomposing  the  parent  to  eliminate  the  complex 
coupling. 

e Rating  values  for  coupling  and  binding  are  additive. 
Many  connections  meet  the  definitions  for  more  than 
one  category  of  the  rating  scale,  and  can  accumulate 
multiple  values.  For  exempli,  If  a diagram  is  both 
"sequentially"  and  "communicationally"  bound,  it  is 
better  in  binding  quality  than  being  atrictly  communica 
tional.  But  if  a connection  is  both  "control"  and 
"record"  - coupled,  it  is  worse  (tnd  more  tightly 
coupled)  then  being  simply  control  or  record  - coupled 
alone. 
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SECTION  7 

DATA  COLLECTION  FOR 
IDEF  MODELING 


CONTROL 


DATA  COLLECTION  FOR 
IDEF  MODELING 


7. 1 Introduction 

When  analyzing  or  designing  any  system,  it  may  be  necessary  to 
obtain  or  verify  facts  about  the  system  or  subject  matter  at  hand.  There 
are  many  sources  of  factual  information.  One  might i 

• read  existing  documents,  using  each  table  of 
contents  and  index  to  locate  needed  information. 

• observe  the  system  in  operation,  if  it  already 
exists. 

• survey  a large  group  of  people,  through  question- 
naires or  other  such  means. 

• talk  to  one  or  more  "exports"  who  possess  the 
desired  knowledge. 

s use  whatever  is  already  known  by  the  author. 

• guess  or  Invent  a hypothetical  description,  and 
ask  rcadera  to  help  bring  it  closer  to  reality. 

Of  all  these  methods,  the  most  important  is  face-to-face  interaction  with 
an  expert.  Seldom  will  all  existing  information  be  written.  Preconceived 
notions  that  are  reflected  in  questionnaires  are  often  faulty. 

Obtaining  information  from  an  uxpert  has  been  formalized  in  an 
Interview  process.  This  step  by  step  process  allows  an  Interview  to 
be  conducted  without  unduly  influencing  the  expert  with  information 
already  obtained  by  the  interviewers. 

A key  part  of  interviewing  is  to  record  the  information  obtained. 
This  can  be  done  cither  as  informal  notes,  as  activity  and  data  lists,  as 
a formal  matrix  of  functions,  or  as  diagram  sketihes. 
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7.2  The  Interview  Process 


The  purpose  of  an  Interview  is  to  gather  information  from  an 
individual  who  possesses  an  expertise  considered  important  to  the 
analytical  effort.  There  are  four  types  of  interviews  that  might  be 
conducted  during  the  course  of  performing  the  anslysis  phase  of  an 
IDEF  project. 

Four  Types  of  Interviews 

a)  Fact  finding  for  understanding  current  operations. 

This  type  of  Interview  is  used  to  establish  the 
content  of  a Current  Operation!  Model,  or  to.  help 
understand  the  existing  environment, 

b)  Problem  Identification  to  assist  in  the  establishment 
of  future  requirements.  This  type  of  interview  is 
used  to  validate  the  Current  Operations  Model  and 
to  provide  the  foundation  for  a Future  Oparationa 
Model , 

c)  Solution  Diacuaelon  regarding  future  system  capa- 
bilities. This  type  of  interview  is  used  to  establish 
the  content  of  a Future  Operations  Model. 

d)  IDEF  Author /Commenter  Talk  Sesalon.  This  type 
of  Interview  Is  used  to  resolve  problems  which  have 
surfaced  during  the  construction  of  an  IDEF  model. 

The  reason  for  identifying  types  of  interviews  is  that  during  the 

course  of  performing  an  actual  interview,  ingredients  of  each  type  appear. 

\ 

Tho  respondent  might  tell  the  interviewer  facts  about  a given  system  in 
terms  of  problems.  Also,  the  respondent  might  identify  problems  in  terms 
of  solutions  to  the  problems.  The  interviewer,  by  constantly  classifying 
the  respondants  remarks,  can  obtain  the  maximum  useful  information  from 
the  interview. 


7.  3 The  Interview  Kit 


It  is  recommended  that  a "standard"  Interview  Kit  be  used  for 
recording  the  interview.  It  may  be  stored  in  an  Interview  File  and  it 
may  be  distributed  to  appropriate  individuals.  Thii  distribution  might 
Include  other  members  on  the  Analysis  team  or  even  the  interview 
respondent  for  corrections,  additions,  and  deletions.  The  interview  kit 
would  contain  t 


1.  Cover  Page  (Kit  cover) 

2.  Interview  and  Record  Follow-up 

a.  Interviewer  Name  (IDEF  Author  Name) 

b.  Interview  Date  (IDEF  Diagram  Date) 

c)  Interview  Duration  (Start  time,  End  time) 

d)  Respondent  Name 

e)  Respondent  Title  and  Organizational  Responsibility 

f)  Respondent  Telephone  Number  and  Extension 

g)  Additional  Sources  of  Information  Identified 

1)  Documents  - Title  and  Location 

2)  Other  Interviewees  - Name,  Title, 
Organizational  Responsibility, 

Address,  Telephone  number 

h)  Essential  Elements  of  Information  - A Summary 
of  the  key  points  covered  in  the  interview, 

i)  Follow-up  questions  and/or  areas  of  concern 
either  not  covered  during  the  interview,  or 
postponed 

j)  New  Terms  for  Project  Glossary 

3.  Activity  and  Data  List 

4.  Interview  Agenda  (Developed  in  preparation  of 
Interview  - This  is  covered  in  following  section) 

5.  Interview  Notes  and  Rough  Diagrams 
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Interview  Guideline* 


There  are  five  stages  to  the  successful  Interview*  each  must  be 
performed  in  order  to  assure  that  the  most  information  is  obtained  and 
recorded  in  the  least  amount  of  timo. 

• Preparation 

• Initialization 

• Interview 

• Termination 

• Finalization 

in  each  stage  of  an  Interview  there  are  certain  basic  activities  which  must 
be  performed.  Additionally,  associated  with  each  stage,  there  exist 
psychological  aids  which  will  help  the  interviewer  establish  an  atmosphere 
of  professionalism  and  trust  with  the  respondent. 

7.4.1  Interview  Preparation 

By  thinking  through  certain  key  interview  needs  before  the  inter- 
view, a more  organized  and  efficient  dialogue  can  be  achieved.  Prepara- 
tion for  an  interview  should  contain,  but  is  not  limited  to,  the  following 
act', vi  ;es ! 

1.  Select  Interviewee 

a)  From  areas  of  responsibility 

b)  From  recommendations  of  others 

c)  From  various  levels  of  the  organiza'ionai 

hierarchy  - upper  levels  useful  for  "big 
picture, " lower  levals  for  detail  information, 
and  middle  levels  for  bridging  the  gap 

2.  Make  Appointment 

a)  Short  duration  - i to  1 hour 

b)  Not  immediately  before  lunch,  nor  late  afternoon 

c)  Identify  purpose  of  interview 
Explain  interviewer  role 


d) 
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Establish  Tentative  Agenda 

a)  Topical  areas  - used  as  a foundation  for 
interview  (this  helps  prepare  "broad 
general  questions") 

b)  Specific  questions 

Review  applicable  background  information 

Review  appropriate  terminology 

Insure  coordination  with  other  interviews 

Check  interview  file  to  ascertain  that  the 
respondent  has  or  has  not  been  previously 
interviewed,  If  the  Interview  is  a follow-up 
interview,  then  examine  the  results  of 
previous  Interviews. 

Fill  out  Interview  Record  d Follow-up  with  pertinent 

Information 

Make  out  Interview  Agenda 


7.4.2  Interview  Initialization 

This  stage  of  the  interview  is  directed  at  establishing  a rapport 
between  the  interviewer  and  respondent.  The  courteay  permitted  by  the 
respondent  at  the  start  of  an  Interview  is  usually  short.  This  time  is 
important  in  motivating  the  respondent  to  help  the  interviewer,  This 
stage  of  the  interview  should  contain  the  following  topless 

1,  Provide  respondent  with  a tangible  means  of  introduction, 
e.g.,  a business  card  (this  removes  doubt  on  the  part  of 
the  respondent  as  to  how  to  pronounce  or  spell  the 

In  Verviewer's  name  and  can  therefore  remove  a frequent 
cause  of  respondent  embarrassment) 

2,  Establish  purpose  of  Interview 

a)  Expand  on  information  provided  in  initial  contact 

b)  Establish  point  of  view  for  the  interview.  Use 
interview  type  l,  2,  3 or  4 as  a basis. 

c)  Establish  purpose  of  the  interview  - even  If  the 
interview  Is  a follow-up  interview. 


3.  Establish  the  acceptability  of  v ote  taking.  The  respondent 
may  require  assurance  of  confidentiality. 

4.  Establish  the  Expert/Author  relationship  - alleviate 

the  fear  that  the  interview  will  be  used  to  tell  the 
respondent  how  to  do  his  job,  oi4  that  the 
respondent's  job  is  in  jeopardy*  - 1 

•''il  . ( . t V 

5.  Start  with  broad  general  questions  which  will  get  the  ’ 
respondent  talking  thdse  should  be  based  upon  the 
topical  areaa  identified  in  the  agenda. 

■ 1 • , ' yi  ■ ' . . v \ 

6.  Ass.es'a  the  reSpondentJs  ability  to  provide  pertinent  ' 
information  - if,  the  information  is  too  general  or  too 
detailed  for  the  stage  of  the  IDEF  model  boing  prepared, 
evaluate  respondent's  ability  to  contribute.  Terminate 
the  interview  if  necessary  - it  may  be  a Waste  of  both 
the  interviewer's  and  respondent's  time. 

7.  , Begin  to  formulate  Specific  questions ‘Which  complement  ..  . , 

the 'agenda. 

M , • • ■ , i ' 

8.  W.'ite,  don't  talk. 


7.4.3  Conducting  the  Interview 

While  it  1b  not  useful  to  define  questions  to  ask  during  an  interview, 
it  is  possible  to  Identify  guidelines  that  should  be  considered  during  the 
interview.  The  first  set  of  guidelines  deals  with  the  qualification  of  the 
information  being  obtained.  The  second  set  of  guidelines  relate  to  the 
stimulation  of  information  flow. 


Information  Qualification  1 The  human  mind  can  comprehend  at 
double  the  rate  at  which  people  speak.  The  danger  in  interviewing  is 
that  this  rate  difference  is  typically  used  by  the  listener  to  think  about 
what  should  bo  said  in  response  Instead  of  about  what  is  being  said, 

To  assist  the  interviewer  in  thinking  about  what  is  being  said, 
there  is  a series  of  questions  which  may  bo  used  to  help  the  interviewer 
keep  his  mind  on  the  information  being  provided) 


e What  supporting  facts  are  being  provided  for  the 
main  points  being  discussed? 

• How  recent  is  the  information? 
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• How  complete  is  the  formation? 

» Do  I really  understand  what  is  being  said? 

• Is  the  level  of  detail  being  presented  appropriate 
for  my  purpose? 

e Are  there  areas  being  omitted?  1 

• Has  this  Information  been  discussed  with  someone  else?  ■ 

• How  important  is  this  information? 

» Are  side-topics  being  discussed? 

• Has  the  interview  viewpoint  changed? 


Information  Flow  Stimulation i The  following  set  of  guidelines  can 
be  used  to  stimulate  the  respondent  into  providing  maximum  reliable 


information  i 

’ 

• 

Keep  extraneous  comments  and  conversations  to  a 
minimum.  The  interview  Is  used  to  obtain  informa- 
tion, not  make  friends,  or  sell  ideas. 

• 

Be  aware  of  the  respondent's  failure  to  identify  problem 
areas  in  the  environment.  This  may  indicate  that  the 
respondent  is  not  it  ease  with  the  interviewer. 

J- 

V 
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• 

Provide  the  respondent  time  to  think.  Do  not  suggest 
answers  or  ssk  another  question . A pause  in  the  inter- 
view is  useful  to  allow  the  respondent  to  recall  vital 
pieces  of  information. 

iV 

:h 

\': 
i r 

i 

* 

Avoid  outside  distractions  which  tend  to  "uncouple" 
the  train  of  thought.  If  at  all  possible,  conduct  inter- 
views outside  of  the  respondent's  normal  habitat. 

i'y 

i: 

% 

7 

e 

Be  aware  of  internal  distractions,  signs  that  the 
respondent  is  not  comfortable  or  at  ease  with  the 
interview. 

• 

Try  to  determine  if  the  information  being  obtained  is 
fact  or  opinion. 

M 

• 

Encourage  elaboration  by  asking  for  a rephrasing  or 
a summary  of  the  information  presented. 

• Ascertain  the  respondent's  background  and  association 
with  the  subject  matter  being  discussed.  Valuable  insight 
Into  the  respondent's  remarks  can  be  obtained  knowing 
his  relationship  to  the  organization  and  existing  systems. 

• Do  not  enter  into  or  encourage  sarcasm  and  humor. 

e Do  not  mention  or  discuss  any  interview  with  another 
person. 

e Record  all  questions  asked  by  the  respondent.  The 
interviewer  should  answer  all  questions  except  those 
dealing  with  user-organization  management,  plans,  or 
personalities. 

e Show  interest  in  what  the  respondent  is  saying. 

e Concentrate  on  the  unfamiliar  and  difficult  aspects  of 
the  subject  being  discussed.  Avoid  the  obvious. 

a Be  alert  for  the  inconsistent  or  Incorrect  use  of  words, 
Ask  for  definitions  for  any  unfamiliar  or  questionable 
term.  Record  the  definition  for  the  project  glossary, 

e Do  not  contradict  the  respondent  even  if  facts  do  not 

support  what  is  being  said.  Use  the  Kit  Cycle  to  resolve 
such  conflicts. 

e Be  humble.  The  respondent  is  the  expert,  not  the 
interviewer . 

e Postpone  subjects  which  cannot  be  fully  covered  within 

the  agreed  upon  time  frame.  Do  not  extend  the  interview 
time,  but  rather  make  another  appointment. 

• Appreciate  different  opinions  on  the  same  subject.  Use 
IDEF  to  show  these  opinions  and  to  resolve  conflicts. 

e Stimulate  the  respondent  with  pertinent  open  ended 
questions. 


7.4.4  Termination 

The  interview  should  be  terminated  for  any  of  the  four  following 
reasons i 

a)  The  information  being  obtained  in  the  interview  is  not 
appropriate. 

b)  The  time  limit  has  been  reached, 
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c)  The  interviewer  haa  been  saturated  with  information. 

d)  There  is  a clash  of  personalities  between  the  interviewer 
and  the  respondent. 

Depending  upon  the  cauae  of  termination,  the  following  topics 
should  be  considered  during  the  termination  of  the  interview! 

e The  interview  should  not  be  closed  abruptly,  but  rather 
should  end  with  a few  minutes  of  informal  discussion. 

e The  main  points  of  the  interview  should  be  summarized. 

e Areas  of  concern  which  have  been  postponed  or  not 
covered  should  be  identified. 

• A follow-up  interview,  if  necessary,  should  be  arranged. 

e The  respondent  should  be  asked  to  recommend  other 
persons  who  should  be  interviewed. 

e If  the  interview  notes  are  to  be  reviewed  by  the 

respondent  prior  to  distribution,  this  fact  should  be 
mentioned  during  the  termination. 

• The  respondent  should  be  thanked  for  his  time  and  effort, 
7.4.5  Finalization 

This  stage  of  the  interview  is  directed  at  assuring  that  the  infor- 
mation obtained  during  the  Interview  is  properly  recorded  and  disseminated 
to  the  project  team.  The  vehicle  used  to  accomplish  the  finalization  of 
an  interview  is  the  Interview  Kit.  If  note  taking  was  not  permitted  by  the 
respondent,  the  interviewer  should,  upon  termination  of  the  interview, 
Immediately  write  down  the  salient  points  discussed.  Finalization  of  the 
interview  includes  the  following: 

a)  Identify  additional  sources  of  information. 

b)  Summarize  the  Essential  Elements  of  Information. 

c)  Identify  new  terms  for  the  project  glossary. 

d)  List  the  follow-up  questions  and  areas  of  concern 
either  postponed  or  not  covered  during  the  interview. 


e)  Complete  Activity  and  Data  List. 

f)  Expand  on  nny  notes  with  any  information  recalled 
during  the  review. 

g)  Prepare  rough  IDEF  diagrams  that  reflect  the  information 
obtained. 

h)  Identify  any  assumptions  being  made 
or  any  items  which  are  not  clear. 

i)  Publish  and  distribute  the  Interview  Kit. 

j)  Address  the  names,  areas  of  expertise,  phone 
numbers , and  addresses  of  persons  mentioned 
in  the  interview. 
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SECTION  8 
IDEFq  GLOSSARY 


Arrow 


A line  representing  data,  Its  source  (no  point)  and 
its  use  (point  on  the  end  of  the  line) . 


Author 


Branch 


The  person  who  prepares  any  IDEF  model. 

A rectangle,  containing  a name  and  number,  used  to 
represent  an  activity. 

A fork  or  a join. 


C -Number 


Commenter 


Context 


Control 


Detail  Reference 
Expression 

Draft 


A chronological  number  used  near  the  lower  right 
hand  corner  of  an  IDEF  diagram  form  tot  uniquely 
Identify  the  diagram)  trace  the  history  and  filing 
of  an  author's  diagrams.  C-numbers  may  be  used 
as  Detail  Reference  Expressions, 

A pointer  (outward  pointer  on  the  bottom  of  a box) 
used  to  show  that  the  box  is  detailed  by  the 
decomposition  of  another  box. 

A person  who  has  enough  training  in  an  IDEF 
technique  to  offer  structured  comments  using  the 
note  numbering  system  and  (often)  referring  to 
flaws  in  the  application  of  the  technique  itself. 

The  Immediate  environment  in  which  a model  is  to 
operatei  the  limits  of  the  model,  In  IDEFg  the 
arrows  around  any  box,  but  particularly  the  box 
on  an  A-O  diagram,  Also,  the  small  box  on  the 
IDEF  form  in  which  the  parent  diagram  and  box  are 
identified . 

The  class  of  arrows  associated  with  the  top  of  an 
IDEFq  box.  Provides  guidance  to  the  transformation, 

Anything  namable  by  a noun  phrase  such  as  things, 
conditions  or  information.  Usually  refers  to  a class 
(such  as  person)  but  may  mean  a single  instance 
( "John  Jones") , 

The  C-number  or  node  number  written  beneath 
an  IDLFq  box  to  show  that  it  is  detailed  and  where. 

An  approval  level  for  an  IDEF  diagram  form  above 
"working"  and  below  "recommended. 11 
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Expert 

FEO 

Fork 

Function 

Gloaaary 

ICOM 

IDEF  Role 
Input 

Join 

Kit 

Kit  Cycle 

Label 

Librarian 

Mechanism 


A person  familiar  with  a part  of  the  real  world 
system  being  modeled.  May  serve  as  a source  of 
Information  or  as  a reviewer  of  part  of  the  model. 

A diagram  "For  Exposition  Only"  in  which  violation 
of  normal  syntactic  rules  ia  allowed. 

The  point  at  which  an  IDEFg  arrow  (going  from 
source  to  use)  divides  into  two  or  more  arrows. 

An  activity  described  by  a verb  phrase  that 
identifies  what  must  be  accomplished. 

A required  section  of  an  IDEF  model  which  defines 
the  way  in  which  worda  or  phraaea  are  used. 


A single  use  of  the  ICOM  code  system.  The 
acronym  of  Input.  Control.  Output.  Mechanism. 

The  arrows  “so  labeled.  “ 

A poaition  in  an  IDEF  project.  See  author,  expert, 
commenter,  reader,  librarian, 

The  arrow  class  associated  with  the  left  hand  aide 
of  an  IDEFq  box.  Usually  becomes  part  of  the 
output. 

The  point  at  which  an  IDEF.  arrow  (going  from 
aource  to  uae)  joins  with  one  or  more  other  arrows 
to  form  a single  arrow. 

The  standardized  packages  of  diagrams  which 
contain  portions  of,  or  complete  to  date,  models 
to  be  reviewed.  See  kit  cycle. 

A formal  procedure  for  obtaining  peer  or  expert 
review  during  model  development. 

The  name  associated  with  an  IDEFg  arrow, 

The  person  responsible  fori 

• routing  and  trucking  of  kits 
e project  files 

The  arrow  class  associated  with  the  bottoms  of 
IDEFq  boxes. 


Model 

Modeler 

Node 

Node  Lift 
Node  Diagram 
Note 

Output 

Parent 

Project 

Project  Manager 

Publication 

Purpose 

Reader 

Recommended 


A representation  of  a system  which  can  be  used  to 
answer  questions  about  the  system. 

An  alternate  term  for  author. 

A point  at  which  subsidiary  parts  originate  or 
center.  The  number  associated  with  an  IDEF-  box 
or  diagram.  (Each  activity  may  be  shown  once 
as  a box  and  once  as  a diagram.) 

A listingt  often  indented,  showing  all  nodes  in  an 
IDEFq  model  in  "outline"  order. 

A graphic  representation  of  the  relationship 
between  the  nodes  of  an  IDEF^  model. 

A comment  on  an  IDEF  diagram  to  record  a fact 
outaide  those  normally  treated  by  the  method  or 
a comment  by  a reader  or  commenter  about  a 
diagram. 

The  clssa  of  arrowa  naaociated  with  the  right 
hand  side  of  the  IDEFQ  boxes.  The  result  of  an 
IDEFg  transformation. 

The  diagram  on  which  the  box  appears  which  is 
detailed  by  the  "offspring"  diagram, 

The  organized  task  for  which  an  IDEF  model  is 
prepared. 

The  member  of  the  project  who  has  final 
responsibility  for  the  finished  product. 

The  highest  approval  level  for  an  IDEF  diagram. 

A brief  statement  of  the  use  to  be  made  of  a 
model  so  that  the  reason  for  its  existence  is  clear, 

A person  with  no,  or  limited,  training  in  an  IDEF 
technique  who  aeee  part  or  alt  of  the  model.  A 
reader  will  often  comment,  but  hie  comments  are 
not  expected  to  be  structured,  Individuals  or 
groups  participating  in  a walkthrough  of  a diagram 
are  normally  grouped  ae  "readers." 

The  next-to-highest  approval  level  for  an  IDEF 
diagram. 
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Technical  Committee  The  group  authorized  to  guide  the  developin''!'!  of 

a model  and,  eventually,  to  approve  Us  contents. 


Text 

Tunnelled 

Viewpoint 

Working 


An  overall  verbal  comment  on  an  IDEFQ  diagram 
appearing  on  a separate  diagram  form. 

Arrow  An  IDEF.  arrow  one  end  of  which  is  not  associated 
with  an  arrow  on  the  parent  or  offspring  diagram, 

An  attempt  to  define  the  subset  of  possible  facts 
within  a context  which  will  be  portrayed.  Often 
expressed  in  terms  of  the  persona  whose  perceptions 
are  portrayed. 

The  lowest  approval  level  for  an  IDEF  diagram, 

All  IDEF  diagrams  are  initially  classified  "working," 


IDEF0  index  of  terms 


' Subject 

* A 

Abstraction  in  Diagrams 
Activation  of  a Box 
Architecture 
Arrows,  Boundary 
Arrows,  Branching 
Arrows,  Bundling 
Arrows,  Call 

Arrows,  Connecting  Boxes 
Arrows,  External 
Arrows,  Incoming,  Outgoing 
Arrows,  Creating  Interface 
Arrows,  Internal 
Arrows,  Joining 
Arrows,  Labeling 
Arrows , Layout 

, Arrows,  Mechanism 

4 Arrows,  Placement  of 

Arrows , Split 
Arrows,  Tunnelled 
Arrows,  Unconnected  (Boundary) 

‘ Author 

Author  Activities 

i Sa>1c  Steps  of  Diagram  Creation 

f Data  Gathering  Phase 

i 

i Structuring  Phase 

f Presentation  Phase 

^ Interaction  Phase 

I Author/Commenter  Notes 


p«q« 

14 

24 
3 

26,  35 

25 
96 
2B 

27 

37 
22 
98 

26 
25 
25 

101 

28 
100 
120 

38 
35 
64 

83 

88 

88 

89 

89 

66 


I HTV’ 


155 


Qfmmm  sms' 


INDEX  (Continued) 


Subject  Page 

B 

Boundaries  3? 

Bounded  Context  14 

Box/Arrow  Relationship  23 

Box  Numbering  21 

Boxtia  21 

3ov.es,  Generating  Function  90 

Boxes i Modifying  95 

Branch  1 ' 25 

Bundling  ' 96 

C 

Call  or  Downward-Pointing  Mechanism  Arrow  28 

Clustering  91 

Commenter,  Comments  64 

Commenting  Guidelines  65 

C-Number  75 

Cohesion,  Measures  and  Types  of  127 

Concepts  8 

C natraint(s)  54,  98 

Context  14 

Context,  Fir'd  74 

Context,  Modifying  97 

. nntoxt,  Purpose  and  Viewpoint,  Selecting  83 

Control(s)  22 

Coupling  and  Cohesion,  Assessing  132 

Coupling  and  Cohesion,  Relationship  121 

Cover  Sheet,  How  to  Fill  Out  68 

Cycle,  If'EF  Kit  62 


INDEX  (Continued) 

Subject 

D 

Data  Collection,  Methods 
Data  Defined 
Data  Gathering  Phase 
Data,  Input  and  Output 
Decompose,  Selecting  a Box  to 
Decomposition 
Decomposition,  Example  of 
Diagram  Creation 
Diagram,  Context 

Diagram  Form,  Standard  How  to  Fill  Out 

Diagram  Parent 

Diagram  Reading 

Diagram  Text 

Diagram  Tree 

Drawing  a Function  Diagram,  Steps 
E 

Experts 

F 

Feedback  or  Iteration 

FEO 

Filets) 

Format,  Page-pair 
Function  Boxes,  Generating 
Function  Defined 
Function  Diagrams,  Definition  of 
Function  Simultaneous 


INDEX  (Continued) 


Subject 

PaSi 

\ 

G 

1 

Glossary 

87 

1 1 

■'$  : 

Oraphic  Layout 

98 

i 

,i  , 

H 

t 

I ! 
1 1 

Hierarchy 

32 

ICAM  Architecture 

ICAM  Definition 

1COM  Codes 

ICOM  Codes , Multiple 

ICOM  Syntax  for  Connecting  Diagrams 

1DEF  Basic  Concepts 

IDEF  Defined 

IDEF  Kits 

IDEF  Model  Walk  Through  Procedure 

Index , Nodes 

Input 

Interaction  Phase 
Interactive  Review  Process 
Interface  Arrows 
Interface  Arrows,  Creating 
Interview,  Proceae 
Iteration  or  Feedback 


Kit  Cover 
Kit  Cycle 
Kits,  Standard 
Kits,  Summary 


3 

3 

37,  98 
56 
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INDEX  (Continued) 


Subject 

Peas 

MWSHS 

L 

Labelling  Arrows 

92 

Layout,  Arrow 

101 

Librarian 

64 

M 

Mechanism , Arrows 

28 

Message  Field 

73 

Model  Defined 

11 

Model  Names 

34 

Model  Quality  Checklist 

106 

Module 

14 

Modifying  Boxes 

95 

N 

Node  Index 

42 

Node  Index /Contents  Sheet 

71 

Node  Numbers 

32 

Node  Tree 

33 

Notes,  Author /Commenter 

66 

Notes  Field 

73 

Number  Field 

75 

Numbering,  Boxes 

21 

0 

Order,  Node  Index 

42 

Output 

22 

INDEX  (Continued) 


Subltct  Page 

P 

Page-pair  Format  49 

Parent  Diagram  13 

Peraonnel  Roles  61 

Presentation  Phase  S2 

Purpose  15 

Purpose  of  Architecture  3 

R 

Reader  64 

Redrawing  96 

Reference  Expressions  32 

References  and  Notes  104 

Redrawing  Diagrams  95 

Review  Process  15 

S 

Semantics  110 

Sequence  25 

Simultaneous  Action  24 

Splitting  91 

Standard  Kit  70 

Status  Field  73 

Structured  Analysts  and  Design  Technique  8 

Structuring  Phase  88 

Submodule,  Limiting  14 

Syntax  106 

System,  Representation  of  14 

System,  Definition  of  19 


INDEX  (Continued) 


1 Subject 

Page 

i T 

| Talk 

66 

! Teamwork,  Disciplined 

15,  61 

i Text 

87 

Text  Numbers 

34 

Text  Writing 

103 

Time 

25 

1 Tree,  Diagram,  Node 

33 

! Tunnelling 

36 

V 

1 Version  0,  1,  2 Defined 

3 

Viewpoint 

15 

W 

! Working  File 

76 

4 

1 
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APPENDIX  A 


SYNOPSES  OF  VOL.  I THROUGH  VOL.  XI 

Vol.  I Architecture  Part  II  Accomplishments 

This  volume  presents  an  overview  of  the  Project,  individual  teak 
overviews  end  recommendation*  for  future  XGAM  projects. 

Vol.  II  Architecture  - A Structured  Approach  to  Manufacturing 

The  ICAM  approach  to  batter  understanding,  communicating  and 
analysing  manufacturing  through  the  development  and  ueo  of  the  Archi- 
tecture is  explained  in  this  volume.  The  reasoning  for  the  development 
of  Architecture,  the  components,  application  and  benefits  are  described 
in  detail. 

Vol.  Ill  Integration  Using  Architecture 

Integration  of  Manufacturing  to  improve  productivity  and  reduce 
manufacturing  coats  is  the  goal  of  the  XCAM  program.  This  volume  details 
the  procedures  for  integrating  systems  and  the  benefits  to  be  gained  from 
integrating  "AS  XS"  models  prior  to  building  "TO  BE"  models.  Two  sub- 
system function  models  integrated  with  the  manufacturing  function  model 
under  this  contract  are  praasntedi 

1.  Integration  of  Manufacturing  Control  - Materials 
Management  Subsystem  IDEFq  Model  into  the 
Manufacturing  IDEFq  Model.  (MCMMO/MPOO) 

2.  Integration  of  Sheet  Metal  Center  IDEFq  Model 
into  the  Manufacturing  IDEFq  Modal.  (5MCO/MFQO) 

Vol.  IV  Function  Modeling  Manual  (IDEFq) 

This  volume  is  the  manual  given  to  students  learning  the  IDEFq 
function  modeling  methodology  for  describing  manufacturing  functions. 


Vol . V Information  Modeling  Manual  ( I DEF 1 ) 

This  volume  ia  the  manual  given  to  student*  learning  the  IDEF^ 
Information  Modeling  Methodology  for  describing  manufacturing  information. 

Vol.  VI  Dynamics  Modeling  Manual  (IDEFj) 

This  volume  Is  the  manual  given  to  students  learning  the  IDEFg 
Dynamics  Modeling  Methodology  for  describing  the  time  varying  behavior 
of  functions  and  information. 


Vol.  VII  Com 
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cture  Product"  (MPOO) 


This  volume  presents  the  composite  view  depicting  manufacturing 
aa  it  exists  today  in  the  form  of  an  ''AS  IS"  Function  Modal  of  Manufacturing. 


Vol.  VIII  Composite  Function  Modal  of  "Deal 


This  volume  presents  the  composite  view  depicting  the  design 
process  ae  it  exiats  today  in  th*  form  of  an  "AS  IS"  Function  Mode',  of 
Design. 

VOL.  IX  Composite  Information  Modal  of  "Manufacture  Product"  (MFG1 


This  volume  present*  the  composite  view  depicting  manufacturing 
as  it  exists  today  in  the  form  of  an  "AS  IS"  Information  Model  of  Manu- 
facturing. Because  of  ita  voluminous  size,  this  model  has  bean  printed 
in  several  parts  to  facilitate  ease  of  handling. 

Vol,  IX,  Part  1 MFG  Development 

This  part  explains  the  process  of  development  that 
the  MFG1  model  has  undergone. 

Vol.  IX.  Part  2 MFG1  Model 

The  MFGl  model  diagrams  and  attribute  claas 
definitiona  compriae  this  part. 
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Vol.  X Dynamics  Model  of  a Sheet  Metal  Canter  Subsystem  (SMC 2) 

This  volume  contains  an  IDEFj  Dynamics  Modal  of  ths  sheet  metal 
center  at  Northrop  Corporation's  Mariposa  facility.  It  demonstrates  the 
application  of  the  IDEFg  Dynamics  Modeling  Methodology. 

Vol.  XI  ICAM  Library  Maintenance  and  Distribution  Procadurss 

Contained  in  this  volume  are  procedures  developed  to  allow  for 
the  proper  dissemination  of  the  material  generated  under  the  ICAM  program. 
They  are  the  ICAM  Program  Library  User's  Quids  and  ICAM  Program 
Library  Maintenance  Procedures. 
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APPENDIX  B 

ARCHITECTURE  PART  II  - FINAL  REPORT 
DOCUMENT  REQUEST  ORDER  FORM 

VOLUME  I Architecture  Part  II  Accomplishment! 

VOLUME  II  - Architecture  - A Structured  Approach  to  Manufacturing 
VOLUME  III  - Integration  Using  Architecture 
VOLUME  IV  - Function  Modeling  Manual  (IDEFQ) 

VOLUME  V - Information  Modeling  Manual  (IDEFj) 

VOLUME  VI  * Dynamics  Modeling  Manual  (IDEF^) 

VOLUME  VII  - Composite  Function  Modal  of  "Manufacture  Product"  (MFCO) 
VOLUME  VIII  - Composite  Function  Model  of  "Design  Product"  (DESICNO) 
VOLUME  IX  - Composite  Information  n.jdal  of  "Manufacture  Product"  (MFC1) 
Part  1 - MFG1  Development 
Part  2 - MFC1  Model 

VOLUME  X - Dynamics  Model  of  a Sheet  Metal  Center  Subsystem  (SMC 2) 
VOLUME  XI  - ICAM  Library  Maintenance  and  Distribution  Procedures 


Submit  document  requests  to:  ICAM  Program  Library 

AFWAL/MLTC 

Wright-Patterson  AFB,  OH  45433 


NAME  . 

TITLE  __ 

COMPANY 

DEPARTMENT  . 

MAIL  CODE  

STREET  OR  P.O.  BOX  

STATE  __ - -ZIP 

PHONE  # 


167 

*U.i.Oov«rnm»nt  Printing  Officti  111  I — lif-00#/®044 


